id,task_title,comment_text,comment_type,cleaned_comment_text,olmo_category 56791,VisualEditor: Editing at top of page shows pawn/slug character,"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}",task_description,"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}",BUG REPRODUCTION 269631,VisualEditor: Editing at top of page shows pawn/slug character,"Change 86685 merged by jenkins-bot: Follow-up to 9b999622: don't slug paragraphs that contain just a text node https://gerrit.wikimedia.org/r/86685",task_subcomment,"Change 86685 merged by jenkins-bot: Follow-up to 9b999622: don't slug paragraphs that contain just a text node GERRIT_URL",ACTION ON ISSUE 269628,VisualEditor: Editing at top of page shows pawn/slug character,*** Bug 54785 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54785 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 269622,VisualEditor: Editing at top of page shows pawn/slug character,"Change 86685 had a related patch set uploaded by Catrope: Follow-up to 9b999622: don't slug paragraphs that contain just a text node https://gerrit.wikimedia.org/r/86685",task_subcomment,"Change 86685 had a related patch set uploaded by Catrope: Follow-up to 9b999622: don't slug paragraphs that contain just a text node GERRIT_URL",ACTION ON ISSUE 56737,Don't release any new VE updates for three months,"**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",task_description,"**Author:** CODE **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",BUG REPRODUCTION 266589,Don't release any new VE updates for three months,"**Wikifram** wrote: Allright, thanks to both for the reply.",task_subcomment,"**Wikifram** wrote: Allright, thanks to both for the reply.",ACTION ON ISSUE 266583,Don't release any new VE updates for three months,"(In reply to comment #4) > Is that an official policy or wishful thinking? VE product manager James Forrester told to Tech Ambassadors at See also http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-September/000416.html ""However, if there is community consensus that your wiki does not want it yet or is not ready, it can of course be reversed to ""opt-in"" - just file a Bugzilla request or contact your local community liaison.""",task_subcomment,"(In reply to comment #4) QUOTE VE product manager James Forrester told to Tech Ambassadors at See also URL ""However, if there is community consensus that your wiki does not want it yet or is not ready, it can of course be reversed to ""opt-in"" - just file a Bugzilla request or contact your local community liaison.""",SOLUTION DISCUSSION 266576,Don't release any new VE updates for three months,"(In reply to comment #4) > MZMcBride, is that an official policy or wishful thinking? I can't an > official statement that declares that the opt-in is now an automatic right of > all Wikipedias if they want it. How official would you like the statement to be? I've declared this both on Bugzilla and on-wiki (on the English Wikipedia). Is there any Wikimedia wiki community having trouble getting VisualEditor switched from opt-out to opt-in?",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE How official would you like the statement to be? I've declared this both on Bugzilla and on-wiki (on the English Wikipedia). Is there any Wikimedia wiki community having trouble getting VisualEditor switched from opt-out to opt-in?",SOLUTION USAGE 266571,Don't release any new VE updates for three months,"**Wikifram** wrote: MZMcBride, is that an official policy or wishful thinking? I can't an official statement that declares that the opt-in is now an automatic right of all Wikipedias if they want it.",task_subcomment,"**Wikifram** wrote: MZMcBride, is that an official policy or wishful thinking? I can't an official statement that declares that the opt-in is now an automatic right of all Wikipedias if they want it.",SOLUTION DISCUSSION 266567,Don't release any new VE updates for three months,"**Wikifram** wrote: While it is an improvement that the wikis can request an opt-in, I'm not interested in that. You (WMF) are pushing untested, deficient software to us, making things even worse when tempers are already running high; we don't have the means to stop your releases apparently (or if we did stop them, some people would again get very upset probably). I'll try to find a better location for this, but this is not about the policy, this is about the VE being one major bug that shouldn't be released at all until it is seriously improved.",task_subcomment,"**Wikifram** wrote: While it is an improvement that the wikis can request an opt-in, I'm not interested in that. You (WMF) are pushing untested, deficient software to us, making things even worse when tempers are already running high; we don't have the means to stop your releases apparently (or if we did stop them, some people would again get very upset probably). I'll try to find a better location for this, but this is not about the policy, this is about the VE being one major bug that shouldn't be released at all until it is seriously improved.",SOLUTION DISCUSSION 266563,Don't release any new VE updates for three months,"I agree with Andre here. Though I'll also point out that, while it's a little less than ideal, any Wikimedia wiki that currently has opt-out VisualEditor deployed can request that VisualEditor be switched to opt-in mode (similar to the setup on the German and English Wikipedias) by establishing a local community consensus. For further info, users should consult [[m:Requesting wiki configuration changes]].",task_subcomment,"I agree with Andre here. Though I'll also point out that, while it's a little less than ideal, any Wikimedia wiki that currently has opt-out VisualEditor deployed can request that VisualEditor be switched to opt-in mode (similar to the setup on the German and English Wikipedias) by establishing a local community consensus. For further info, users should consult [[m:Requesting wiki configuration changes]].",SOLUTION USAGE 266557,Don't release any new VE updates for three months,"Discussing deployment policies is nothing that should happen in a technical bugtracker (however once a discussion *has* taken place in a better suited place, the request for changing the configuration based on that consensus can be filed as a ticket in Bugzilla). Please take this discussion to the talk page or to the mailing list instead to *discuss* this request first, as statements here seem to be rather subjective (which does not necessarily mean ""wrong"" though). Thanks for your understanding.",task_subcomment,"Discussing deployment policies is nothing that should happen in a technical bugtracker (however once a discussion *has* taken place in a better suited place, the request for changing the configuration based on that consensus can be filed as a ticket in Bugzilla). Please take this discussion to the talk page or to the mailing list instead to *discuss* this request first, as statements here seem to be rather subjective (which does not necessarily mean ""wrong"" though). Thanks for your understanding.",ACTION ON ISSUE 56712,VisualEditor: Snowmen appear near newly added references,"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",task_description,"See last line of this diff: URL . Steps to reproduce, as provided by user: Seudo. 1) Go to URL - 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 URL instead. Thanks. -------------------------- **Version**: unspecified **Severity**: critical **See Also**: URL",BUG REPRODUCTION 264896,VisualEditor: Snowmen appear near newly added references,"(In reply to Elitre from comment #22) > More examples from it.wp: > https://it.wikipedia.org/w/index. > php?title=Natale_Ciravolo&diff=67212907&oldid=67197341 , > https://it.wikipedia.org/w/index.php?title=Utente:Nnvu/ > Sandbox1&diff=prev&oldid=67108020 . This is bug 67992 I think.",task_subcomment,"(In reply to Elitre from comment #22) QUOTE QUOTE QUOTE QUOTE QUOTE This is bug 67992 I think.",ACTION ON ISSUE 264891,VisualEditor: Snowmen appear near newly added references,"More examples from it.wp: https://it.wikipedia.org/w/index.php?title=Natale_Ciravolo&diff=67212907&oldid=67197341 , https://it.wikipedia.org/w/index.php?title=Utente:Nnvu/Sandbox1&diff=prev&oldid=67108020 .",task_subcomment,"More examples from it.wp: URL , URL .",SOLUTION USAGE 264886,VisualEditor: Snowmen appear near newly added references,"I believe this is happening again at it.wp. See https://it.wikipedia.org/w/index.php?title=AA.VV.&diff=prev&oldid=67188720 (snowmen) or https://it.wikipedia.org/w/index.php?title=Utente:Elitre_(WMF)/Pagina_delle_prove_VE&diff=next&oldid=67195802 (pawn). What you need to reproduce: just create a base reference, add the template Cita, add something as its first parameter, then hit Space/type something else in the reference before saving.",task_subcomment,"I believe this is happening again at it.wp. See URL (snowmen) or URL (pawn). What you need to reproduce: just create a base reference, add the template Cita, add something as its first parameter, then hit Space/type something else in the reference before saving.",BUG REPRODUCTION 264881,VisualEditor: Snowmen appear near newly added references,"Um, folks, this may be happening again... please see bug:61272...",task_subcomment,"Um, folks, this may be happening again... please see bug:61272...",BUG REPRODUCTION 264877,VisualEditor: Snowmen appear near newly added references,*** Bug 54976 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54976 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 264873,VisualEditor: Snowmen appear near newly added references,"(In reply to comment #12) > Change 87455 had a related patch set uploaded by Catrope: > When cloning the InternalList, pass through properties that aren't rebuilt > > https://gerrit.wikimedia.org/r/87455 I just deployed this change, and the article linked in comment 0 now works for me on frwiki.",task_subcomment,"(In reply to comment #12) QUOTE QUOTE QUOTE QUOTE I just deployed this change, and the article linked in comment 0 now works for me on frwiki.",SOLUTION USAGE 264869,VisualEditor: Snowmen appear near newly added references,"Change 87459 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87459",task_subcomment,"Change 87459 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264863,VisualEditor: Snowmen appear near newly added references,"Change 87458 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87458",task_subcomment,"Change 87458 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264855,VisualEditor: Snowmen appear near newly added references,"Change 87455 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87455",task_subcomment,"Change 87455 merged by jenkins-bot: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264849,VisualEditor: Snowmen appear near newly added references,"Change 87459 had a related patch set uploaded by Jforrester: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87459",task_subcomment,"Change 87459 had a related patch set uploaded by Jforrester: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264844,VisualEditor: Snowmen appear near newly added references,"Change 87458 had a related patch set uploaded by Jforrester: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87458",task_subcomment,"Change 87458 had a related patch set uploaded by Jforrester: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264837,VisualEditor: Snowmen appear near newly added references,"Change 87455 had a related patch set uploaded by Catrope: When cloning the InternalList, pass through properties that aren't rebuilt https://gerrit.wikimedia.org/r/87455",task_subcomment,"Change 87455 had a related patch set uploaded by Catrope: When cloning the InternalList, pass through properties that aren't rebuilt GERRIT_URL",TASK PROGRESS 264833,VisualEditor: Snowmen appear near newly added references,*** Bug 54917 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54917 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 264828,VisualEditor: Snowmen appear near newly added references,I was able to reproduce this on that frwiki article just now. I get the same error about group.firstNodes[group2] being undefined. Investigating further.,task_subcomment,I was able to reproduce this on that frwiki article just now. I get the same error about group.firstNodes[group2] being undefined. Investigating further.,INVESTIGATION AND EXPLORATION 264823,VisualEditor: Snowmen appear near newly added references,Being able to add references without corrupting the article is a core requirement. Updating the severity to critical.,task_subcomment,Being able to add references without corrupting the article is a core requirement. Updating the severity to critical.,BUG REPRODUCTION 264817,VisualEditor: Snowmen appear near newly added references,"Same for me too, it appears literally impossible to add a reference without snowmen and a bogus reference tag (FF 24.0, Windows 7): https://en.wikipedia.org/w/index.php?title=X_Window_System&diff=575630218&oldid=575623976",task_subcomment,"Same for me too, it appears literally impossible to add a reference without snowmen and a bogus reference tag (FF 24.0, Windows 7): URL",BUG REPRODUCTION 264811,VisualEditor: Snowmen appear near newly added references,"Could this please have a priority assigned? Other editors are finding it a blocker to editing with references: This bug is really annoying! Every time I add a new reference I can't do anything after it because whatever I click on my keyboard the snowmen appear! Even clicking backspace to delete them multiplies them along with already existing text! Only way to get out of there is to cancel my edit and lose the work I've done! :/ Basically, VE can't be used almost at all at this point, since every addition to an article has to have a reference too! Is there any information about when this bug will get fixed? TeamGale 04:35, 3 October 2013 (UTC)",task_subcomment,"Could this please have a priority assigned? Other editors are finding it a blocker to editing with references: This bug is really annoying! Every time I add a new reference I can't do anything after it because whatever I click on my keyboard the snowmen appear! Even clicking backspace to delete them multiplies them along with already existing text! Only way to get out of there is to cancel my edit and lose the work I've done! :/ Basically, VE can't be used almost at all at this point, since every addition to an article has to have a reference too! Is there any information about when this bug will get fixed? TeamGale 04:35, 3 October 2013 (UTC)",BUG REPRODUCTION 264806,VisualEditor: Snowmen appear near newly added references,"My edit above to [[OpenOffice.org]] was in Firefox 24.0, Ubuntu 12.04 distro version.",task_subcomment,"My edit above to [[OpenOffice.org]] was in Firefox 24.0, Ubuntu 12.04 distro version.",BUG REPRODUCTION 264801,VisualEditor: Snowmen appear near newly added references,"An instance of this from en.wp. David Gerard reports: Dig this: https://en.wikipedia.org/w/index.php?title=OpenOffice.org&diff=575290819&oldid=575267859 What I was trying to do was add PladaoOffice and a reference link, which appeared to add correctly in the VE. Then I noticed there was a full stop after ""SunShine Office"", so I clicked on it to put the cursor there, and VE added a pile of ""☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃"", and more each time I clicked again. Note also that my carefully constructed reference is gone, leaving only """", and it's added another spurious one of those higher up",task_subcomment,"An instance of this from en.wp. David Gerard reports: Dig this: URL What I was trying to do was add PladaoOffice and a reference link, which appeared to add correctly in the VE. Then I noticed there was a full stop after ""SunShine Office"", so I clicked on it to put the cursor there, and VE added a pile of ""☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃☃"", and more each time I clicked again. Note also that my carefully constructed reference is gone, leaving only """", and it's added another spurious one of those higher up",BUG REPRODUCTION 264796,VisualEditor: Snowmen appear near newly added references,"Please replace the word ""pawns"" with ""snowmen"". Sorry for the confusion.",task_subcomment,"Please replace the word ""pawns"" with ""snowmen"". Sorry for the confusion.",ACTION ON ISSUE 264791,VisualEditor: Snowmen appear near newly added references,"**seudeau** wrote: That looks like https://bugzilla.wikimedia.org/show_bug.cgi?id=53642, which is quite old though. I also tried to reproduced in a user-specific test page, but couldn't.",task_subcomment,"**seudeau** wrote: That looks like URL which is quite old though. I also tried to reproduced in a user-specific test page, but couldn't.",BUG REPRODUCTION 264787,VisualEditor: Snowmen appear near newly added references,"**seudeau** wrote: %%%*** Bug 54708 has been marked as a duplicate of this bug. ***%%%",task_subcomment,"**seudeau** wrote: %%%*** Bug 54708 has been marked as a duplicate of this bug. ***%%%",ACTION ON ISSUE 264782,VisualEditor: Snowmen appear near newly added references,"A last comment from the user, <<[...] Sometimes the following error appears, ""Javascript Error: Cannot open another window while another one is active"". Sometimes the text of the page breaks down completely and the browser gets stuck. Do not try to look at what's on line 54 of load.php, you'll give up quickly :-)>>",task_subcomment,"A last comment from the user, <<[...] Sometimes the following error appears, ""Javascript Error: Cannot open another window while another one is active"". Sometimes the text of the page breaks down completely and the browser gets stuck. Do not try to look at what's on line 54 of load.php, you'll give up quickly :-)>>",BUG REPRODUCTION 56375,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","For example, you can't copy/paste in the edit summary box. -------------------------- **Version**: unspecified **Severity**: major",task_description,"For example, you can't copy/paste in the edit summary box. -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 250036,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85784 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85784",task_subcomment,"Change 85784 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",ACTION ON ISSUE 250028,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85783 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85783",task_subcomment,"Change 85783 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",ACTION ON ISSUE 250019,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85784 had a related patch set uploaded by Catrope: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85784",task_subcomment,"Change 85784 had a related patch set uploaded by Catrope: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",ACTION ON ISSUE 250011,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85783 had a related patch set uploaded by Catrope: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85783",task_subcomment,"Change 85783 had a related patch set uploaded by Catrope: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",ACTION ON ISSUE 250007,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85204 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85204",task_subcomment,"Change 85204 merged by jenkins-bot: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",ACTION ON ISSUE 250004,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Change 85204 had a related patch set uploaded by Esanders: Only listen for copy/paste on documentNode and pasteTarget https://gerrit.wikimedia.org/r/85204",task_subcomment,"Change 85204 had a related patch set uploaded by Esanders: Only listen for copy/paste on documentNode and pasteTarget GERRIT_URL",SOLUTION DISCUSSION 250001,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Marking as a regression as this is new behaviour in the latest release (version ""false"")",task_subcomment,"Marking as a regression as this is new behaviour in the latest release (version ""false"")",BUG REPRODUCTION 249997,"VisualEditor: [Regression] Copy/paste handlers intercept non-surface copy/paste events, even after VE is closed","Pasting from an external source into the edit summary box works fine for me. However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. To reproduce: 1. Load any page in VisualEditor. 2. Do any of i. Press the browser back button to exit VE ii. Cancel the edit iii. make an edit and then save the page 3. Select any text anywhere on the page and copy it to the clipboard 4. Try to paste that text anywhere (search box, URL bar, text editor, etc) Expected behaviour: Selected text is copied and pasted Actual behaviour: Selected text is not copied and pasted",task_subcomment,"Pasting from an external source into the edit summary box works fine for me. However, once a page has been loaded in VE you cannot copy any text on that page until you reload - even after you have closed VE. To reproduce: 1. Load any page in VisualEditor. 2. Do any of i. Press the browser back button to exit VE ii. Cancel the edit iii. make an edit and then save the page 3. Select any text anywhere on the page and copy it to the clipboard 4. Try to paste that text anywhere (search box, URL bar, text editor, etc) Expected behaviour: Selected text is copied and pasted Actual behaviour: Selected text is not copied and pasted",BUG REPRODUCTION 56341,VisualEditor: [Regression] Unnamed references get their names corrupted,"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",task_description,"URL For some reason, multiple different unnamed references all get name="":3"" there. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",BUG REPRODUCTION 248008,VisualEditor: [Regression] Unnamed references get their names corrupted,*** Bug 54445 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54445 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 247999,VisualEditor: [Regression] Unnamed references get their names corrupted,"James, I think it can be confusing that the name and the number of a reference do not match, although the links work. See https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575128343&oldid=575128003 (the reference #2 gets a ref name:3).",task_subcomment,"James, I think it can be confusing that the name and the number of a reference do not match, although the links work. See URL (the reference #2 gets a ref name:3).",SOLUTION USAGE 247992,VisualEditor: [Regression] Unnamed references get their names corrupted,*** Bug 54654 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54654 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 247985,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85781 merged by jenkins-bot: Prevent naming collisions when generating unique reference names https://gerrit.wikimedia.org/r/85781",task_subcomment,"Change 85781 merged by jenkins-bot: Prevent naming collisions when generating unique reference names GERRIT_URL",ACTION ON ISSUE 247979,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85780 merged by jenkins-bot: Prevent naming collisions when generating unique reference names https://gerrit.wikimedia.org/r/85780",task_subcomment,"Change 85780 merged by jenkins-bot: Prevent naming collisions when generating unique reference names GERRIT_URL",ACTION ON ISSUE 247974,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85781 had a related patch set uploaded by Catrope: Prevent naming collisions when generating unique reference names https://gerrit.wikimedia.org/r/85781",task_subcomment,"Change 85781 had a related patch set uploaded by Catrope: Prevent naming collisions when generating unique reference names GERRIT_URL",ACTION ON ISSUE 247968,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85780 had a related patch set uploaded by Catrope: Prevent naming collisions when generating unique reference names https://gerrit.wikimedia.org/r/85780",task_subcomment,"Change 85780 had a related patch set uploaded by Catrope: Prevent naming collisions when generating unique reference names GERRIT_URL",ACTION ON ISSUE 247964,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85144 merged by jenkins-bot: Prevent naming collisions when generating unique reference names https://gerrit.wikimedia.org/r/85144",task_subcomment,"Change 85144 merged by jenkins-bot: Prevent naming collisions when generating unique reference names GERRIT_URL",ACTION ON ISSUE 247961,VisualEditor: [Regression] Unnamed references get their names corrupted,"Change 85144 had a related patch set uploaded by Catrope: Failing test for bug https://gerrit.wikimedia.org/r/85144",task_subcomment,"Change 85144 had a related patch set uploaded by Catrope: Failing test for bug GERRIT_URL",TASK PROGRESS 247957,VisualEditor: [Regression] Unnamed references get their names corrupted,"Isolated test case: https://en.wikipedia.org/wiki/User:Ed_g2s/Sandbox4 Diagnosis: The automatically generated names are based on the number of distinct references in the page up to that point, indexed at zero. The first unnamed tag is the 4th distinct reference on the page (it's preceded by two :1s, a :3 and a :0), so its autogenerated name is :3. However, there so happens to already be a literal on the page, so we get a naming collision and the whole thing goes to hell. In practice, this situation can only arise after multiple iterations of duplicating unnamed references with VE (which adds tags to the source), then removing or reordering references so the ref tags are aligned exactly right for this bug to occur.",task_subcomment,"Isolated test case: URL Diagnosis: The automatically generated names are based on the number of distinct references in the page up to that point, indexed at zero. The first unnamed tag is the 4th distinct reference on the page (it's preceded by two :1s, a :3 and a :0), so its autogenerated name is :3. However, there so happens to already be a literal on the page, so we get a naming collision and the whole thing goes to hell. In practice, this situation can only arise after multiple iterations of duplicating unnamed references with VE (which adds tags to the source), then removing or reordering references so the ref tags are aligned exactly right for this bug to occur.",BUG REPRODUCTION 56047,VisualEditor: Corruption with circumflexes,"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: ""êttt"" 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",task_description,"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: ""êttt"" 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",BUG REPRODUCTION 254900,VisualEditor: Corruption with circumflexes,"Marking as a duplicate of bug 53680 which I believe is indeed the issue. *** This bug has been marked as a duplicate of bug 53680 ***",task_subcomment,"Marking as a duplicate of bug 53680 which I believe is indeed the issue. *** This bug has been marked as a duplicate of bug 53680 ***",ACTION ON ISSUE 254898,VisualEditor: Corruption with circumflexes,"This is a dupe of bug 53747, bug 53680 or both.",task_subcomment,"This is a dupe of bug 53747, bug 53680 or both.",BUG REPRODUCTION 254894,VisualEditor: Corruption with circumflexes,"Also, circumflexes that are entered in VE are completely stripped on save. Instead, characters are jumping around to its location.",task_subcomment,"Also, circumflexes that are entered in VE are completely stripped on save. Instead, characters are jumping around to its location.",BUG REPRODUCTION 55747,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"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",task_description,"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: URL This is repeatedly breaking page text on the Polish Wikipedia, so I'm marking the bug ""highest critical"". -------------------------- **Version**: unspecified **Severity**: critical **URL**: URL **See Also**: URL",BUG REPRODUCTION 237176,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"It seems like it does actually fix the issue (for me at least). Thanks. So that means editing will have been completely broken for only three weeks straight by the time this gets deployed :/",task_subcomment,"It seems like it does actually fix the issue (for me at least). Thanks. So that means editing will have been completely broken for only three weeks straight by the time this gets deployed :/",SOLUTION USAGE 237170,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",task_subcomment,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",ACTION ON ISSUE 237164,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"Ok, the patch is merged, and due to go live on mediawiki.org by 13 September 2013: https://gerrit.wikimedia.org/r/#/c/82858/ Please let us know whether it fixes the bug!",task_subcomment,"Ok, the patch is merged, and due to go live on mediawiki.org by 13 September 2013: URL Please let us know whether it fixes the bug!",SOLUTION USAGE 237160,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"I'm optimistic that the following patch will fix this bug: https://gerrit.wikimedia.org/r/#/c/82858/ If someone can test this hypothesis, great; if not, then I will hopefully be able to do so later today.",task_subcomment,"I'm optimistic that the following patch will fix this bug: URL If someone can test this hypothesis, great; if not, then I will hopefully be able to do so later today.",SOLUTION DISCUSSION 237153,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,Is there any progress on this? Because today's the point when I'd suggest reverting the deployment to last known good version if nobody is going to fix this.,task_subcomment,Is there any progress on this? Because today's the point when I'd suggest reverting the deployment to last known good version if nobody is going to fix this.,TASK PROGRESS 237146,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"I've tested this on master in Firefox under Ubuntu -- I managed to replicate the behavior not just in polish, but also Spanish diacritics but only when these are ""added on"". Trying to add diacritic to an existing character produced a pawn and then some odd duplication of characters. That did not happen when I typed in either Hebrew or Arabic in master. Another thing I found is that there seems to be a difference between an already-combined diacritic (like ñ which is native to the Spanish keyboard) and an ""added"" diacritic. When I typed the native ñ nothing broke, it added it properly and the behavior was correct. And finally, the typing broke and the pawn appeared only when I tried to add diacritic to a latin letter. When I tried to add ""niqqud"" to Hebrew letters, though, like pressing ש and left-Alt+a to produce שְ the behavior was as expected (no pawn, no problem)",task_subcomment,"I've tested this on master in Firefox under Ubuntu -- I managed to replicate the behavior not just in polish, but also Spanish diacritics but only when these are ""added on"". Trying to add diacritic to an existing character produced a pawn and then some odd duplication of characters. That did not happen when I typed in either Hebrew or Arabic in master. Another thing I found is that there seems to be a difference between an already-combined diacritic (like ñ which is native to the Spanish keyboard) and an ""added"" diacritic. When I typed the native ñ nothing broke, it added it properly and the behavior was correct. And finally, the typing broke and the pawn appeared only when I tried to add diacritic to a latin letter. When I tried to add ""niqqud"" to Hebrew letters, though, like pressing ש and left-Alt+a to produce שְ the behavior was as expected (no pawn, no problem)",BUG REPRODUCTION 237139,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,Bug 53680 shows this also happens on en.wp and fr.wp and is independent of keyboard layout.,task_subcomment,Bug 53680 shows this also happens on en.wp and fr.wp and is independent of keyboard layout.,BUG REPRODUCTION 237130,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"https://pl.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Opinie&oldid=37428181#.C4.99 is a pretty good explanation, and makes clear it's not browser (or OS) dependent.",task_subcomment,"URL is a pretty good explanation, and makes clear it's not browser (or OS) dependent.",SOLUTION DISCUSSION 237120,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"Actually, I sort of have reproduced it now. I used Opera 12, but some users at pl.wp reported it happening on Chrome – it's probably not browser-dependent. You'll probably need to set your system keyboard to ""Polish (programmer's)"" or similarly named one. (It's the same as standard US layout, but includes the AltGr diacritics. A ""Polish (typist's)"" layout exists on some systems, but nobody ever uses it, so forget it.) 1. Try inputting some text with diacritics, such as the ""Pójdź, kińże tę chmurność w głąb flaszy!"" sentence above (copying and pasting text with diacritics doesn't cause issues, you need to type it). (Strings of one character such as ""ąąąą"" tend to work correctly for some reason.) 2. Depending on your luck, it might look okay, or you might get parts of the sentence duplicated in the next paragraph. Regardless of that, try backspacing a little now. The cursor will likely be moved to someplace in the next paragraph and unrelated characters will be removed. 3. Try previewing the changes. The text will differ from the one shown in editing view.",task_subcomment,"Actually, I sort of have reproduced it now. I used Opera 12, but some users at pl.wp reported it happening on Chrome – it's probably not browser-dependent. You'll probably need to set your system keyboard to ""Polish (programmer's)"" or similarly named one. (It's the same as standard US layout, but includes the AltGr diacritics. A ""Polish (typist's)"" layout exists on some systems, but nobody ever uses it, so forget it.) 1. Try inputting some text with diacritics, such as the ""Pójdź, kińże tę chmurność w głąb flaszy!"" sentence above (copying and pasting text with diacritics doesn't cause issues, you need to type it). (Strings of one character such as ""ąąąą"" tend to work correctly for some reason.) 2. Depending on your luck, it might look okay, or you might get parts of the sentence duplicated in the next paragraph. Regardless of that, try backspacing a little now. The cursor will likely be moved to someplace in the next paragraph and unrelated characters will be removed. 3. Try previewing the changes. The text will differ from the one shown in editing view.",BUG REPRODUCTION 237112,VisualEditor breaks when Polish-language diacritics (ążśźęćńół) are input,"Examples of edits apparently exhibiting this issue: * https://pl.wikipedia.org/w/index.php?title=Rondo&curid=122034&diff=37421631&oldid=35999089 - ""Największe rondo"" -> ""Najwi kszerondo"" * https://pl.wikipedia.org/w/index.php?title=Euronews&diff=prev&oldid=37394282 - ""dostpna"" should be ""dostępna"", ""Midzyrnodowym"" should be ""Międzynarodowym"", etc. * https://pl.wikipedia.org/w/index.php?title=1967&diff=next&oldid=37422197 - ""ki rapers"" should probably be ""Amerykański raper"" (both occurences - this happened on two consecutive edits) Results of a user trying to type in ""Pójdź, kińże tę chmurność w głąb flaszy!"" when reproducing this bug: * https://www.mediawiki.org/w/index.php?title=User:G%C5%BCdacz&oldid=775661 * https://www.mediawiki.org/w/index.php?title=User:G%C5%BCdacz&oldid=775666",task_subcomment,"Examples of edits apparently exhibiting this issue: * URL - ""Największe rondo"" -> ""Najwi kszerondo"" * URL - ""dostpna"" should be ""dostępna"", ""Midzyrnodowym"" should be ""Międzynarodowym"", etc. * URL - ""ki rapers"" should probably be ""Amerykański raper"" (both occurences - this happened on two consecutive edits) Results of a user trying to type in ""Pójdź, kińże tę chmurność w głąb flaszy!"" when reproducing this bug: * URL * URL",BUG REPRODUCTION 55680,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"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",task_description,"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**: URL",BUG REPRODUCTION 257414,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,*** Bug 54047 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54047 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 257411,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",task_subcomment,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",ACTION ON ISSUE 257405,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013: https://gerrit.wikimedia.org/r/#/c/82858/ Please let us know whether it fixes the bug!",task_subcomment,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013: URL Please let us know whether it fixes the bug!",SOLUTION USAGE 257400,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"(In reply to comment #3) > Same as bug 53747? Yes. I don't want to just merge them though as they're assigned to different people.",task_subcomment,"(In reply to comment #3) QUOTE Yes. I don't want to just merge them though as they're assigned to different people.",ACTION ON ISSUE 257393,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,Same as bug 53747?,task_subcomment,Same as bug 53747?,BUG REPRODUCTION 257386,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"K7L comments: ""I am seeing the same problems if I try to edit ordinary text such as the article intro. Pressing or even makes accented characters in newly-edited text vanish. This editor is not usable for non-English text on this browser [firefox]."" This needs to be fixed urgently.",task_subcomment,"K7L comments: ""I am seeing the same problems if I try to edit ordinary text such as the article intro. Pressing or even makes accented characters in newly-edited text vanish. This editor is not usable for non-English text on this browser [firefox]."" This needs to be fixed urgently.",BUG REPRODUCTION 257381,VisualEditor: annotating or linking newly added text containing accented or non-Latin characters causes corruption and pawns,"Now also reported on the French Wikipedia: [[:fr:Route 2 (Ontario)]] and its revision history, the distance chart is a table and Unicode descriptive text added with VisualEditor didn't save properly.[https://fr.wikipedia.org/w/index.php?title=Route_2_%28Ontario%29&diff=96342109&oldid=96342028] The damage was fixed using the standard MW wiki source editor but is still in history. Try inserting « La route 2 va à Montréal (Québec) » (or something/anything that isn't US ASCII) into a table cell and watch it fail to display correctly or fail to save. The fr.wp reported was using an unspecified version of firefox on Vector in Ubuntu. I use Firefox 23 on monobook in Xubuntu. Raising this to critical as being able to use all characters in a language is essential.",task_subcomment,"Now also reported on the French Wikipedia: [[:fr:Route 2 (Ontario)]] and its revision history, the distance chart is a table and Unicode descriptive text added with VisualEditor didn't save properly.[URL The damage was fixed using the standard MW wiki source editor but is still in history. Try inserting « La route 2 va à Montréal (Québec) » (or something/anything that isn't US ASCII) into a table cell and watch it fail to display correctly or fail to save. The fr.wp reported was using an unspecified version of firefox on Vector in Ubuntu. I use Firefox 23 on monobook in Xubuntu. Raising this to critical as being able to use all characters in a language is essential.",BUG REPRODUCTION 55334,Parsoid: Annotated text after a template is deleted,"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",task_description,"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: URL 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",BUG REPRODUCTION 237055,Parsoid: Annotated text after a template is deleted,This is the same Parsoid bug that affected both places where we implicitly assumed that the 'about' id is always present (without realizing/checking that it could be absent for VE-inserted transclusions).,task_subcomment,This is the same Parsoid bug that affected both places where we implicitly assumed that the 'about' id is always present (without realizing/checking that it could be absent for VE-inserted transclusions).,MOTIVATION 237050,Parsoid: Annotated text after a template is deleted," *** This bug has been marked as a duplicate of bug 53434 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 53434 ***",ACTION ON ISSUE 237046,Parsoid: Annotated text after a template is deleted,"HTML

barquux

Expected wikitext {{Inline|Foo}}'''bar'''quux Actual wikitext {{Inline|Foo}}quux :(",task_subcomment,"HTML

barquux

Expected wikitext {{Inline|Foo}}'''bar'''quux Actual wikitext {{Inline|Foo}}quux :(",BUG REPRODUCTION 237040,Parsoid: Annotated text after a template is deleted,"This does not require pre-existing formatted or linked text. The bug also appears if you enter the template first and then add bold word(s) immediately afterwards (no space between the template and the text), starting from an empty page or in a new paragraph. For example, using VisualEditor with the intention of producing this, in this order: {{unreferenced}}'''Hello world''' from Wikipedia. actually results in this: {{unreferenced}} from Wikipedia. If you add a space or hit return after the template, then it works as expected.",task_subcomment,"This does not require pre-existing formatted or linked text. The bug also appears if you enter the template first and then add bold word(s) immediately afterwards (no space between the template and the text), starting from an empty page or in a new paragraph. For example, using VisualEditor with the intention of producing this, in this order: {{unreferenced}}'''Hello world''' from Wikipedia. actually results in this: {{unreferenced}} from Wikipedia. If you add a space or hit return after the template, then it works as expected.",BUG REPRODUCTION 55219,VisualEditor: [Regression] Link inspector prevents insertion of section links,"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}",task_description,"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}",BUG REPRODUCTION 254794,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 112898 merged by jenkins-bot: Include fragments in normalizedTitle https://gerrit.wikimedia.org/r/112898",task_subcomment,"Change 112898 merged by jenkins-bot: Include fragments in normalizedTitle GERRIT_URL",SOLUTION USAGE 254789,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 112898 had a related patch set uploaded by Esanders: Include fragments in normalizedTitle https://gerrit.wikimedia.org/r/112898",task_subcomment,"Change 112898 had a related patch set uploaded by Esanders: Include fragments in normalizedTitle GERRIT_URL",SOLUTION USAGE 254783,VisualEditor: [Regression] Link inspector prevents insertion of section links,"(In reply to comment #10) > Unless I'm missing something obvious, I can't make this work anymore on it.wp > or Mediawiki. It will just ignore the #name_of_the_section if I add it to an > existing wikilink and therefore, it will not recognize the link as edited and > the Save button will stay greyed out. Split that issue into bug 61221.",task_subcomment,"(In reply to comment #10) QUOTE QUOTE QUOTE QUOTE Split that issue into bug 61221.",ACTION ON ISSUE 254776,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Unless I'm missing something obvious, I can't make this work anymore on it.wp or Mediawiki. It will just ignore the #name_of_the_section if I add it to an existing wikilink and therefore, it will not recognize the link as edited and the Save button will stay greyed out.",task_subcomment,"Unless I'm missing something obvious, I can't make this work anymore on it.wp or Mediawiki. It will just ignore the #name_of_the_section if I add it to an existing wikilink and therefore, it will not recognize the link as edited and the Save button will stay greyed out.",BUG REPRODUCTION 254771,VisualEditor: [Regression] Link inspector prevents insertion of section links,… and now deployed.,task_subcomment,… and now deployed.,SOLUTION USAGE 254763,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80507 merged by Catrope: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80507",task_subcomment,"Change 80507 merged by Catrope: Modify regex to allow section links as valid titles GERRIT_URL",ACTION ON ISSUE 254756,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80505 merged by Catrope: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80505",task_subcomment,"Change 80505 merged by Catrope: Modify regex to allow section links as valid titles GERRIT_URL",ACTION ON ISSUE 254749,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80507 had a related patch set uploaded by Jforrester: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80507",task_subcomment,"Change 80507 had a related patch set uploaded by Jforrester: Modify regex to allow section links as valid titles GERRIT_URL",SOLUTION USAGE 254743,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80505 had a related patch set uploaded by Jforrester: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80505",task_subcomment,"Change 80505 had a related patch set uploaded by Jforrester: Modify regex to allow section links as valid titles GERRIT_URL",TASK PROGRESS 254736,VisualEditor: [Regression] Link inspector prevents insertion of section links,This is now fixed in master; we'll cherry-pick it and push live this afternoon. Sorry for the problem.,task_subcomment,This is now fixed in master; we'll cherry-pick it and push live this afternoon. Sorry for the problem.,SOLUTION USAGE 254726,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80417 merged by jenkins-bot: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80417",task_subcomment,"Change 80417 merged by jenkins-bot: Modify regex to allow section links as valid titles GERRIT_URL",SOLUTION USAGE 254717,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Change 80417 had a related patch set uploaded by Esanders: Modify regex to allow section links as valid titles https://gerrit.wikimedia.org/r/80417",task_subcomment,"Change 80417 had a related patch set uploaded by Esanders: Modify regex to allow section links as valid titles GERRIT_URL",SOLUTION USAGE 254708,VisualEditor: [Regression] Link inspector prevents insertion of section links,"Ah, good that someone already reported. Confirmed in mediawiki.org.",task_subcomment,"Ah, good that someone already reported. Confirmed in mediawiki.org.",MOTIVATION 54608,VisualEditor: Template gets removed without editing it,"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",task_description,"Steps to reproduce: 1. Go to URL 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",BUG REPRODUCTION 244141,VisualEditor: Template gets removed without editing it,Moving to date we likely fixed this with the changes to DM.,task_subcomment,Moving to date we likely fixed this with the changes to DM.,SOLUTION USAGE 244134,VisualEditor: Template gets removed without editing it,"I can't reproduce it anymore either, so I'm closing it.",task_subcomment,"I can't reproduce it anymore either, so I'm closing it.",ACTION ON ISSUE 244125,VisualEditor: Template gets removed without editing it,"* ""I can't reproduce"" ... the issue. :)",task_subcomment,"* ""I can't reproduce"" ... the issue. :)",BUG REPRODUCTION 244114,VisualEditor: Template gets removed without editing it,"I can't reproduce but the infobox invocation has some garbage in it. {{Interventions infobox | Name = Post and core | Image = |sesuiatu Caption = |sasa ICD10 = |sasas ICD9 = |sasasasa MeshID = D011176 | OPS301 = |sasas OtherCodes = |sasa }}",task_subcomment,"I can't reproduce but the infobox invocation has some garbage in it. {{Interventions infobox | Name = Post and core | Image = |sesuiatu Caption = |sasa ICD10 = |sasas ICD9 = |sasasasa MeshID = D011176 | OPS301 = |sasas OtherCodes = |sasa }}",INVESTIGATION AND EXPLORATION 244104,VisualEditor: Template gets removed without editing it,"Roan, thoughts? Selser issue?",task_subcomment,"Roan, thoughts? Selser issue?",ACTION ON ISSUE 54466,"VisualEditor: Fix violation of PHP strict standard (""Only variables should be passed by reference in VisualEditor/ApiVisualEditor.php on line 255"")","[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",task_description,"[error] PHP Strict Standards: Only variables should be passed by reference in /srv/phase3/extensions/VisualEditor/ApiVisualEditor.php on line 255, referer: URL -------------------------- **Version**: unspecified **Severity**: trivial",BUG REPRODUCTION 235746,"VisualEditor: Fix violation of PHP strict standard (""Only variables should be passed by reference in VisualEditor/ApiVisualEditor.php on line 255"")",Now fixed in master. Sorry for the slip-up.,task_subcomment,Now fixed in master. Sorry for the slip-up.,SOLUTION USAGE 235742,"VisualEditor: Fix violation of PHP strict standard (""Only variables should be passed by reference in VisualEditor/ApiVisualEditor.php on line 255"")","Change 77362 merged by jenkins-bot: Fix notice caused by not passing the WebRequest object by reference https://gerrit.wikimedia.org/r/77362",task_subcomment,"Change 77362 merged by jenkins-bot: Fix notice caused by not passing the WebRequest object by reference GERRIT_URL",SOLUTION USAGE 235740,"VisualEditor: Fix violation of PHP strict standard (""Only variables should be passed by reference in VisualEditor/ApiVisualEditor.php on line 255"")","Change 77362 had a related patch set uploaded by Catrope: Fix notice caused by not passing the WebRequest object by reference https://gerrit.wikimedia.org/r/77362",task_subcomment,"Change 77362 had a related patch set uploaded by Catrope: Fix notice caused by not passing the WebRequest object by reference GERRIT_URL",SOLUTION USAGE 54420,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link","<> 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",task_description,"<> 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",BUG REPRODUCTION 233184,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link",Fixed and will be deployed tonight.,task_subcomment,Fixed and will be deployed tonight.,SOLUTION USAGE 233177,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link","Change 77264 merged by jenkins-bot: Don't override link target input value while typing https://gerrit.wikimedia.org/r/77264",task_subcomment,"Change 77264 merged by jenkins-bot: Don't override link target input value while typing GERRIT_URL",ACTION ON ISSUE 233170,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link","Change 77264 had a related patch set uploaded by Trevor Parscal: Don't override link target input value while typing https://gerrit.wikimedia.org/r/77264",task_subcomment,"Change 77264 had a related patch set uploaded by Trevor Parscal: Don't override link target input value while typing GERRIT_URL",TASK PROGRESS 233163,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link","I did not know this was a competition, so more from me as well! :p The ""workaround"" is what I mentioned earlier, but it won't always work. With it I managed to get ""Lettere"": it autocompleted to Letteratura, then I put the ""e"" after the first ""r"" and cut the rest. But, it did not work to get to ""Lettera"", which was my intended outcome. This also happens if I am interested in, say, ""Letteratura tedesca"": it won't appear in the drop down list, and I am not even allowed to write it. The only way to get there is writing ""letteraturatedesca"" instead, and adding the space later. This makes sense to VE! Thanks.",task_subcomment,"I did not know this was a competition, so more from me as well! :p The ""workaround"" is what I mentioned earlier, but it won't always work. With it I managed to get ""Lettere"": it autocompleted to Letteratura, then I put the ""e"" after the first ""r"" and cut the rest. But, it did not work to get to ""Lettera"", which was my intended outcome. This also happens if I am interested in, say, ""Letteratura tedesca"": it won't appear in the drop down list, and I am not even allowed to write it. The only way to get there is writing ""letteraturatedesca"" instead, and adding the space later. This makes sense to VE! Thanks.",WORKAROUNDS 233158,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link","I was 25 seconds too slow reporting Bug 52421, but I did include 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 Network Graphics]], [[Classic (album)]] or [[Thing (assembly)]]. I've also found a workaround - continue typing the link you want after it's suggestion, then select and delete what it inserted that you don't want.",task_subcomment,"I was 25 seconds too slow reporting Bug 52421, but I did include 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 Network Graphics]], [[Classic (album)]] or [[Thing (assembly)]]. I've also found a workaround - continue typing the link you want after it's suggestion, then select and delete what it inserted that you don't want.",BUG REPRODUCTION 233154,"VisualEditor: autocomplete for wikilinks ""aggressively"" chooses what to link",*** Bug 52421 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52421 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 54368,VisualEditor.php attempts to register a hook handler that was removed,"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",task_description,"VisualEditor.php attempts to register a hook handler that was removed (summary credit goes to Ori) stack: URL Tim says: QUOTE array(2) { [0]=> string(42) ""VisualEditorHooks::onBeforeWelcomeCreation"" [1]=> string(44) ""GettingStartedHooks::onBeforeWelcomeCreation"" } QUOTE QUOTE 1 -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 254987,VisualEditor.php attempts to register a hook handler that was removed,"I removed the BeforeWelcomeCreation handler in I8be6198a6 but not the statement in VisualEditor.php that registered it. 1.22wmf11 had not yet been updated to I8be6198a6, so it didn't need to be fixed. 1.22wmf12 did need a fix, but there was a merged change separating the deployed commit and my fix: change I1cd9e2bea. I didn't know if it was safe to deploy and no one from the VE team was around, so I created a cut a 'bug/52368' branch based on the deployed commit, cherry picked the fix on top, and synced that. My apologies to the VisualEditor team and to the users that were affected.",task_subcomment,"I removed the BeforeWelcomeCreation handler in I8be6198a6 but not the statement in VisualEditor.php that registered it. 1.22wmf11 had not yet been updated to I8be6198a6, so it didn't need to be fixed. 1.22wmf12 did need a fix, but there was a merged change separating the deployed commit and my fix: change I1cd9e2bea. I didn't know if it was safe to deploy and no one from the VE team was around, so I created a cut a 'bug/52368' branch based on the deployed commit, cherry picked the fix on top, and synced that. My apologies to the VisualEditor team and to the users that were affected.",SOLUTION DISCUSSION 254979,VisualEditor.php attempts to register a hook handler that was removed,Ia4e2a7854b3a2a5cbbe4da,task_subcomment,Ia4e2a7854b3a2a5cbbe4da,ACTION ON ISSUE 54317,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"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}",task_description,"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**: URL **Attached**: {F11781}",BUG REPRODUCTION 252313,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,*** Bug 52328 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52328 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 252309,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,This is fixed and being pushed live right now.,task_subcomment,This is fixed and being pushed live right now.,SOLUTION USAGE 252305,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"Change 76935 merged by jenkins-bot: ve.ui.Toolbar: Emit position event on toolbar instead of surface https://gerrit.wikimedia.org/r/76935",task_subcomment,"Change 76935 merged by jenkins-bot: ve.ui.Toolbar: Emit position event on toolbar instead of surface GERRIT_URL",SOLUTION USAGE 252298,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,*** Bug 52346 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52346 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 252292,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"Whatamidoing's link is to the Polish Wikipedia: [[pl:Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian]]",task_subcomment,"Whatamidoing's link is to the Polish Wikipedia: [[pl:Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian]]",SOLUTION USAGE 252288,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"I have a report of this sort of problem with a misplaced save dialog box appearing in the lower left corner. The editor is running Linux Mint 14 and Firefox 18.0.2. See http://i40.tinypic.com/2eojvh1.jpg and http://i41.tinypic.com/30wqpnb.jpg for his screenshots. The original problem description can be found at Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian",task_subcomment,"I have a report of this sort of problem with a misplaced save dialog box appearing in the lower left corner. The editor is running Linux Mint 14 and Firefox 18.0.2. See URL and URL for his screenshots. The original problem description can be found at Wikipedia:VisualEditor/Opinie#b.C5.82.C4.99dnie_wy.C5.9Bwietlaj.C4.85ce_si.C4.99_okno_opisu_zmian",BUG REPRODUCTION 252282,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"Basically it attaches to whichever toolbar is positioned last. So if you click on a link, and then open the save dialog, it pops up there. If you then scroll down (which updates position of platform toolbar), it moves to that one.",task_subcomment,"Basically it attaches to whichever toolbar is positioned last. So if you click on a link, and then open the save dialog, it pops up there. If you then scroll down (which updates position of platform toolbar), it moves to that one.",SOLUTION DISCUSSION 252274,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"Change 76935 had a related patch set uploaded by Krinkle: ve.ui.Toolbar: Emit position event on toolbar instead of surface https://gerrit.wikimedia.org/r/76935",task_subcomment,"Change 76935 had a related patch set uploaded by Krinkle: ve.ui.Toolbar: Emit position event on toolbar instead of surface GERRIT_URL",TASK PROGRESS 252268,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"Renamed. Removing the link to bug 49969 - the save dialog isn't (yet) an actual dialog, so that would have no effect. Adding a link to bug 52326 which is possibly caused by the same",task_subcomment,"Renamed. Removing the link to bug 49969 - the save dialog isn't (yet) an actual dialog, so that would have no effect. Adding a link to bug 52326 which is possibly caused by the same",SOLUTION DISCUSSION 252263,VisualEditor: [Regression] Save dialog sometimes attaches to context menu toolbar instead of platform toolbar,"There is a lot of discussion about this at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Save_page_box_drops.2C_button_invisible_without_scrolling_..._but_fixes_itself_given_time including two screenshots: [[File:VE save form off screen.png]] and [[File:VE misplaced save box.jpg]] From my testing it seems that if an element is selected (picture, link, template) when you click save then the dialog aligns itself to the top right of that element, regardless of whether there is space on screen for it, with scroll bars if there isn't sufficient vertical space in the window to show the whole dialog. If you close the dialog, deselect the element then open the save box again it appears in the same place, only based on what that element is in the view now. If you close and select a different element then save, it relates to that element. If you have not selected any elements during your edit it appears overthe save button. Steps to reproduce: 1. Edit a page in VE 2. Make a change to the page (doesn't matter what) 3. Click on an element (link, image, template) near the lower left edge of the window. 4. Click the save button in the top right.",task_subcomment,"There is a lot of discussion about this at URL including two screenshots: [[File:VE save form off screen.png]] and [[File:VE misplaced save box.jpg]] From my testing it seems that if an element is selected (picture, link, template) when you click save then the dialog aligns itself to the top right of that element, regardless of whether there is space on screen for it, with scroll bars if there isn't sufficient vertical space in the window to show the whole dialog. If you close the dialog, deselect the element then open the save box again it appears in the same place, only based on what that element is in the view now. If you close and select a different element then save, it relates to that element. If you have not selected any elements during your edit it appears overthe save button. Steps to reproduce: 1. Edit a page in VE 2. Make a change to the page (doesn't matter what) 3. Click on an element (link, image, template) near the lower left edge of the window. 4. Click the save button in the top right.",BUG REPRODUCTION 54232,Anonymous users getting VisualEditor on German Wikipedia and making edits,"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",task_description,"URL --- 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**: URL",INVESTIGATION AND EXPLORATION 247334,Anonymous users getting VisualEditor on German Wikipedia and making edits,"(In reply to comment #7) > I'm sorry if we were dismissive earlier. When I said ""VE doesn't work the way > you think it does"", what I meant to say was ""despite the confusing way these > variables are named, they mean something slightly different, such that one of > them is unused if the other one is set a certain way"". I wasn't annoyed with you (and you weren't the person quoted in comment 6). You're wonderful and I adore you.",task_subcomment,"(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE I wasn't annoyed with you (and you weren't the person quoted in comment 6). You're wonderful and I adore you.",SOCIAL CONVERSATION 247330,Anonymous users getting VisualEditor on German Wikipedia and making edits,"(In reply to comment #6) > I'm fairly annoyed that I was told that VisualEditor ""doesn't work the way > you > think it does"" this morning and my patch sets were roundly and soundly > ignored > (in favor of Gerrit change #76516), only to have the exact changes > implemented a few hours later after this bug appeared. Your patchsets weren't ignored, we worked off them. At the time we honestly believed that this was unnecessary, and the code that uses them is written in a way that leads the reader to believe that it is unnecessary: if wmgVisualEditorDefault is false, wmgVisualEditorDisableForAnons is unused. However, caching threw a wrench in all of this. Two wrongs made a right, if you will. I'm sorry if we were dismissive earlier. When I said ""VE doesn't work the way you think it does"", what I meant to say was ""despite the confusing way these variables are named, they mean something slightly different, such that one of them is unused if the other one is set a certain way"".",task_subcomment,"(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Your patchsets weren't ignored, we worked off them. At the time we honestly believed that this was unnecessary, and the code that uses them is written in a way that leads the reader to believe that it is unnecessary: if wmgVisualEditorDefault is false, wmgVisualEditorDisableForAnons is unused. However, caching threw a wrench in all of this. Two wrongs made a right, if you will. I'm sorry if we were dismissive earlier. When I said ""VE doesn't work the way you think it does"", what I meant to say was ""despite the confusing way these variables are named, they mean something slightly different, such that one of them is unused if the other one is set a certain way"".",SOLUTION DISCUSSION 247327,Anonymous users getting VisualEditor on German Wikipedia and making edits,"For the record, if my patch set from Gerrit changeset 76199 and Gerrit changeset 76468 had been merged and deployed, this bug never would have happened. I'm fairly annoyed that I was told that VisualEditor ""doesn't work the way you think it does"" this morning and my patch sets were roundly and soundly ignored (in favor of Gerrit changeset 76516), only to have the exact changes implemented a few hours later after this bug appeared.",task_subcomment,"For the record, if my patch set from Gerrit changeset 76199 and Gerrit changeset 76468 had been merged and deployed, this bug never would have happened. I'm fairly annoyed that I was told that VisualEditor ""doesn't work the way you think it does"" this morning and my patch sets were roundly and soundly ignored (in favor of Gerrit changeset 76516), only to have the exact changes implemented a few hours later after this bug appeared.",SOLUTION USAGE 247323,Anonymous users getting VisualEditor on German Wikipedia and making edits,"(In reply to comment #4) > Roan's putting this in place now. Done. This bug should stop happening in the next ~10 minutes.",task_subcomment,"(In reply to comment #4) QUOTE Done. This bug should stop happening in the next ~10 minutes.",SOLUTION USAGE 247318,Anonymous users getting VisualEditor on German Wikipedia and making edits,"(In reply to comment #0) > 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). We don't mix user preference cache between logged-in users and logged-out users, this is definitely not what's happening. What's happening is that a while ago the 'visualeditor-enable' preference was enabled by default on de.wikipedia.org. Though it was disabled for anonymous users by other means, that preference was there and as such is cached inside the anonymous user cache that visited pages while VE was enabled by default on de.wikipedia.org. The 'other' means to disable for anons have been removed now that the preference is disabled again on de.wikipedia (it is now an opt-in for logged-in users). However this other means is not cached inside the page but globally from the startup module. So people visiting the pages generated while VE was enabled by default are now getting VE since there is no 'disableForAnons' flag in place. Roan's putting this in place now.",task_subcomment,"(In reply to comment #0) QUOTE QUOTE QUOTE QUOTE We don't mix user preference cache between logged-in users and logged-out users, this is definitely not what's happening. What's happening is that a while ago the 'visualeditor-enable' preference was enabled by default on de.wikipedia.org. Though it was disabled for anonymous users by other means, that preference was there and as such is cached inside the anonymous user cache that visited pages while VE was enabled by default on de.wikipedia.org. The 'other' means to disable for anons have been removed now that the preference is disabled again on de.wikipedia (it is now an opt-in for logged-in users). However this other means is not cached inside the page but globally from the startup module. So people visiting the pages generated while VE was enabled by default are now getting VE since there is no 'disableForAnons' flag in place. Roan's putting this in place now.",SOLUTION DISCUSSION 247311,Anonymous users getting VisualEditor on German Wikipedia and making edits,"Change 76552 merged by jenkins-bot: Explicitly disable VE for anons on dewiki https://gerrit.wikimedia.org/r/76552",task_subcomment,"Change 76552 merged by jenkins-bot: Explicitly disable VE for anons on dewiki GERRIT_URL",TASK PROGRESS 247303,Anonymous users getting VisualEditor on German Wikipedia and making edits,"Change 76552 had a related patch set uploaded by Catrope: Explicitly disable VE for anons on dewiki https://gerrit.wikimedia.org/r/76552",task_subcomment,"Change 76552 had a related patch set uploaded by Catrope: Explicitly disable VE for anons on dewiki GERRIT_URL",ACTION ON ISSUE 247296,Anonymous users getting VisualEditor on German Wikipedia and making edits,"This appears to be a caching issue, yes",task_subcomment,"This appears to be a caching issue, yes",BUG REPRODUCTION 54202,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","**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",task_description,"**Author:** CODE **Description:** According to URL 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**: URL URL",FUTURE PLAN 245474,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","**nrp** wrote: (In reply to comment #16) > (In reply to comment #15) > > So De Wikipedia holds a quick poll and their deployment is changed to opt-in, > > but on En Wikipedia, despite weeks of complaints, we are still stuck with > > opt-out? How does that work? > > If you can hold a coordinated vote on the English Wikipedia and get over 400 > participants to agree to switch to opt-in, I imagine you can get the same > result. :-) I think a quick look at the feedback and other related pages would show a consensus for a switch to opt-in, but in any event there is now an RFC: http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC",task_subcomment,"**nrp** wrote: (In reply to comment #16) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I think a quick look at the feedback and other related pages would show a consensus for a switch to opt-in, but in any event there is now an RFC: URL",SOLUTION DISCUSSION 245468,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","(In reply to comment #15) > So De Wikipedia holds a quick poll and their deployment is changed to opt-in, > but on En Wikipedia, despite weeks of complaints, we are still stuck with > opt-out? How does that work? If you can hold a coordinated vote on the English Wikipedia and get over 400 participants to agree to switch to opt-in, I imagine you can get the same result. :-)",task_subcomment,"(In reply to comment #15) QUOTE QUOTE QUOTE If you can hold a coordinated vote on the English Wikipedia and get over 400 participants to agree to switch to opt-in, I imagine you can get the same result. :-)",SOLUTION DISCUSSION 245462,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","**nrp** wrote: So De Wikipedia holds a quick poll and their deployment is changed to opt-in, but on En Wikipedia, despite weeks of complaints, we are still stuck with opt-out? How does that work?",task_subcomment,"**nrp** wrote: So De Wikipedia holds a quick poll and their deployment is changed to opt-in, but on En Wikipedia, despite weeks of complaints, we are still stuck with opt-out? How does that work?",SOLUTION USAGE 245456,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia",Closing this bug now as the issue in c13 should be resolved by bug 52232. The intention of this bug report is done.,task_subcomment,Closing this bug now as the issue in c13 should be resolved by bug 52232. The intention of this bug report is done.,ACTION ON ISSUE 245449,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","It seems that some IPs can use VE, see e.g. http://de.wikipedia.org/w/index.php?title=Medien_%28Land%29&curid=132736&diff=121014468&oldid=120989155 (tagged as Visual editor), see also the talk on the village pump https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#VE_f.C3.BCr_IP_funktioniert.3F",task_subcomment,"It seems that some IPs can use VE, see e.g. URL (tagged as Visual editor), see also the talk on the village pump URL",SOLUTION DISCUSSION 245441,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","Change 76468 abandoned by MZMcBride: Explicitly disable VisualEditor by default on dewiki Reason: I feel like a Wikipedia user who finally makes his first edit only to have it reverted. ;-) https://gerrit.wikimedia.org/r/76468",task_subcomment,"Change 76468 abandoned by MZMcBride: Explicitly disable VisualEditor by default on dewiki Reason: I feel like a Wikipedia user who finally makes his first edit only to have it reverted. ;-) GERRIT_URL",ACTION ON ISSUE 245434,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","(In reply to comment #7) > (In reply to comment #6) > >... VisualEditor will be temporarily switched back into opt-in mode on > > the German Wikipedia. We don’t intend to otherwise alter the near-term > > VisualEditor deployment schedule > > Does that mean opt-in for everyone or just registered users? Opt-in for everyone, that is to say it's off unless you turn it on in your preferences. In practice, anonymous users won't be able to opt in unless they create an account, because anons can't change their preferences.",task_subcomment,"(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Opt-in for everyone, that is to say it's off unless you turn it on in your preferences. In practice, anonymous users won't be able to opt in unless they create an account, because anons can't change their preferences.",SOLUTION DISCUSSION 245426,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia",This is now done.,task_subcomment,This is now done.,TASK PROGRESS 245418,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","Change 76516 merged by jenkins-bot: Switch VisualEditor back to alpha (opt-in) mode on dewiki https://gerrit.wikimedia.org/r/76516",task_subcomment,"Change 76516 merged by jenkins-bot: Switch VisualEditor back to alpha (opt-in) mode on dewiki GERRIT_URL",ACTION ON ISSUE 245412,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","Change 76516 had a related patch set uploaded by Jforrester: Switch VisualEditor back to alpha (opt-in) mode on dewiki https://gerrit.wikimedia.org/r/76516",task_subcomment,"Change 76516 had a related patch set uploaded by Jforrester: Switch VisualEditor back to alpha (opt-in) mode on dewiki GERRIT_URL",ACTION ON ISSUE 245406,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","**jsalsman** wrote: (In reply to comment #6) >... VisualEditor will be temporarily switched back into opt-in mode on > the German Wikipedia. We don’t intend to otherwise alter the near-term > VisualEditor deployment schedule Does that mean opt-in for everyone or just registered users?",task_subcomment,"**jsalsman** wrote: (In reply to comment #6) QUOTE QUOTE QUOTE Does that mean opt-in for everyone or just registered users?",SOLUTION DISCUSSION 245398,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","In response to community feedback, VisualEditor will be temporarily switched back into opt-in mode on the German Wikipedia. We don’t intend to otherwise alter the near-term VisualEditor deployment schedule, except in case of emergencies. As we did in the case of Dutch Wikipedia, for instance, which was exempted from the phase 2 rollout, we try to accommodate community concern in the process of this rollout. VisualEditor is the single largest and most disruptive change to the user experience in the history of our projects. Not only is it still beta software, it also depends on us working together in partnership to update documentation, add template metadata (which is used by VisualEditor to make templates more user-friendly), and deal with unexpected issues. We appreciate your patience and feedback, and we have no intent of taking your partnership for granted. We also recognize that there are still significant areas for improvement (e.g. performance, handling of tables, insertion of special characters) as well as work we can do to reduce the incidence rate of problematic markup changes. As we continue to support the beta where it is deployed, we’ll also update the German Wikipedia community on progress in these areas, and prepare for re-enabling VisualEditor later in the calendar year. As a reminder, VisualEditor has always been optional to use, and can now also be completely hidden from the user experience (as an individual preference) in wikis where it is enabled by default. -- James Forrester, Product Manager, VisualEditor team ---- Als Reaktion auf die Rückmeldungen der deutschsprachigen Wikipedia-Gemeinschaft werden wir den VisualEditor dort temporär wieder nur per Opt-In verfügbar machen. Darüber hinaus beabsichtigen wir nicht, die unmittelbare Planung für andere Sprachversionen zu verändern, es sei denn, es treten schwerwiegende Probleme auf. Wie auch z.B. im Fall der niederländischen Wikipedia, die von Phase 2 der Beta ausgenommen wurde, versuchen wir, bei der weiteren Aktivierung des VisualEditor mit den Sprachversionen zusammen zu arbeiten und nehmen Bedenken ernst. VisualEditor ist die weitgehendste Änderung an der Benutzeroberfläche in der Geschichte unserer Projekte. VisualEditor ist aber noch Beta-Software, und der Erfolg des Projekts hängt sehr davon ab, dass wir ein einer positiven Partnerschaft zusammen arbeiten, um z.B. Vorlagen-Metadaten (TemplateData) hinzuzufügen (die von VisualEditor verwendet werden, um die Benutzeroberfläche für Vorlagen zu verbessern) und Dokumentation zu aktualisieren, und um mit Software-Problemen umzugehen. Wir schätzen die Geduld und das ehrliche Feedback der deutschsprachigen Wikipedia-Gemeinschaft, und gehen nicht davon aus, dass eine Kooperation ohne gegenseitiges Entgegenkommen funktionieren kann. Wir erkennen auch an, dass es im VisualEditor noch viel Raum für Verbesserungen gibt. Das beinhaltet z.B. Performance, bessere Unterstützung für Tabellen und einen Dialog für das Einfügen von Sonderzeichen. In einigen Fällen können wir auch das Verhalten des Editors optimieren, um unerwünschte Änderungen am Wikitext zu reduzieren. Auch auf der deutschsprachigen Wikipedia werden Verbesserungen selbstverständlich für Opt-In-Nutzer kontinuierlich zur Verfügung stehen, und wir werden regelmäßige Ankündigungen über Neuerungen veröffentlichen. Unser Ziel ist eine Wiederaktivierung des VisualEditor in der Beta-Konfiguration später im Kalenderjahr. Die Verwendung von Wikitext wird selbstverständlich auch nach der Wiederaktivierung des VisualEditor möglich sein. Der VisualEditor ist und bleibt optional, und kann während der Beta-Phase auch komplett aus der Benutzeroberfläche entfernt werden. -- James Forrester, Produktmanager, VisualEditor-Team",task_subcomment,"In response to community feedback, VisualEditor will be temporarily switched back into opt-in mode on the German Wikipedia. We don’t intend to otherwise alter the near-term VisualEditor deployment schedule, except in case of emergencies. As we did in the case of Dutch Wikipedia, for instance, which was exempted from the phase 2 rollout, we try to accommodate community concern in the process of this rollout. VisualEditor is the single largest and most disruptive change to the user experience in the history of our projects. Not only is it still beta software, it also depends on us working together in partnership to update documentation, add template metadata (which is used by VisualEditor to make templates more user-friendly), and deal with unexpected issues. We appreciate your patience and feedback, and we have no intent of taking your partnership for granted. We also recognize that there are still significant areas for improvement (e.g. performance, handling of tables, insertion of special characters) as well as work we can do to reduce the incidence rate of problematic markup changes. As we continue to support the beta where it is deployed, we’ll also update the German Wikipedia community on progress in these areas, and prepare for re-enabling VisualEditor later in the calendar year. As a reminder, VisualEditor has always been optional to use, and can now also be completely hidden from the user experience (as an individual preference) in wikis where it is enabled by default. -- James Forrester, Product Manager, VisualEditor team ---- Als Reaktion auf die Rückmeldungen der deutschsprachigen Wikipedia-Gemeinschaft werden wir den VisualEditor dort temporär wieder nur per Opt-In verfügbar machen. Darüber hinaus beabsichtigen wir nicht, die unmittelbare Planung für andere Sprachversionen zu verändern, es sei denn, es treten schwerwiegende Probleme auf. Wie auch z.B. im Fall der niederländischen Wikipedia, die von Phase 2 der Beta ausgenommen wurde, versuchen wir, bei der weiteren Aktivierung des VisualEditor mit den Sprachversionen zusammen zu arbeiten und nehmen Bedenken ernst. VisualEditor ist die weitgehendste Änderung an der Benutzeroberfläche in der Geschichte unserer Projekte. VisualEditor ist aber noch Beta-Software, und der Erfolg des Projekts hängt sehr davon ab, dass wir ein einer positiven Partnerschaft zusammen arbeiten, um z.B. Vorlagen-Metadaten (TemplateData) hinzuzufügen (die von VisualEditor verwendet werden, um die Benutzeroberfläche für Vorlagen zu verbessern) und Dokumentation zu aktualisieren, und um mit Software-Problemen umzugehen. Wir schätzen die Geduld und das ehrliche Feedback der deutschsprachigen Wikipedia-Gemeinschaft, und gehen nicht davon aus, dass eine Kooperation ohne gegenseitiges Entgegenkommen funktionieren kann. Wir erkennen auch an, dass es im VisualEditor noch viel Raum für Verbesserungen gibt. Das beinhaltet z.B. Performance, bessere Unterstützung für Tabellen und einen Dialog für das Einfügen von Sonderzeichen. In einigen Fällen können wir auch das Verhalten des Editors optimieren, um unerwünschte Änderungen am Wikitext zu reduzieren. Auch auf der deutschsprachigen Wikipedia werden Verbesserungen selbstverständlich für Opt-In-Nutzer kontinuierlich zur Verfügung stehen, und wir werden regelmäßige Ankündigungen über Neuerungen veröffentlichen. Unser Ziel ist eine Wiederaktivierung des VisualEditor in der Beta-Konfiguration später im Kalenderjahr. Die Verwendung von Wikitext wird selbstverständlich auch nach der Wiederaktivierung des VisualEditor möglich sein. Der VisualEditor ist und bleibt optional, und kann während der Beta-Phase auch komplett aus der Benutzeroberfläche entfernt werden. -- James Forrester, Produktmanager, VisualEditor-Team",SOLUTION DISCUSSION 245392,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","Change 76468 had a related patch set uploaded by MZMcBride: Explicitly disabled VisualEditor by default on dewiki https://gerrit.wikimedia.org/r/76468",task_subcomment,"Change 76468 had a related patch set uploaded by MZMcBride: Explicitly disabled VisualEditor by default on dewiki GERRIT_URL",ACTION ON ISSUE 245385,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","Change 76199 had a related patch set uploaded by MZMcBride: Enable anonymous use of VisualEditor on es/fr/he/it/pl/ru/sv https://gerrit.wikimedia.org/r/76199",task_subcomment,"Change 76199 had a related patch set uploaded by MZMcBride: Enable anonymous use of VisualEditor on es/fr/he/it/pl/ru/sv GERRIT_URL",ACTION ON ISSUE 245381,"VisualEditor: Change to opt-in for registered users, postpone activation for IPs on the German Wikipedia","VisualEditor's configuration variables are a bit confusing to me, but it seems like the German Wikipedia would like to reverse part of this change: . wmgVisualEditorDefault would be set to false for dewiki. wmgVisualEditorDisableForAnons would be left as true for dewiki. Is this correct?",task_subcomment,"VisualEditor's configuration variables are a bit confusing to me, but it seems like the German Wikipedia would like to reverse part of this change: on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare"," -------------------------- **Version**: unspecified **Severity**: major",task_description," -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 253214,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare",Now fixed.,task_subcomment,Now fixed.,SOLUTION USAGE 253211,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","Change 76220 merged by jenkins-bot: Don't compare annotations directly with ve.compare() https://gerrit.wikimedia.org/r/76220",task_subcomment,"Change 76220 merged by jenkins-bot: Don't compare annotations directly with ve.compare() GERRIT_URL",ACTION ON ISSUE 253206,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","Change 76220 had a related patch set uploaded by Jforrester: Don't compare annotations directly with ve.compare() https://gerrit.wikimedia.org/r/76220",task_subcomment,"Change 76220 had a related patch set uploaded by Jforrester: Don't compare annotations directly with ve.compare() GERRIT_URL",SOLUTION USAGE 253199,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","(In reply to comment #4) > https://www.mediawiki.org/w/index.php?title=Extension:MassMessage/ > Design&oldid=745378&veaction=edit > > When I go to this URL in Google Chrome/OS X/Version 27.0.1453.116, I get the > following error in my JavaScript console: > > Uncaught RangeError: Maximum call stack size exceeded > oo.compare > oo.compare […] This is now masked by some significant performance improvements we made (so it ""works""), but we think it's still an issue; keeping open.",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE […] This is now masked by some significant performance improvements we made (so it ""works""), but we think it's still an issue; keeping open.",SOLUTION DISCUSSION 253193,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","https://www.mediawiki.org/w/index.php?title=Extension:MassMessage/Design&oldid=745378&veaction=edit When I go to this URL in Google Chrome/OS X/Version 27.0.1453.116, I get the following error in my JavaScript console: Uncaught RangeError: Maximum call stack size exceeded oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare",task_subcomment,"URL When I go to this URL in Google Chrome/OS X/Version 27.0.1453.116, I get the following error in my JavaScript console: Uncaught RangeError: Maximum call stack size exceeded oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare oo.compare",BUG REPRODUCTION 253190,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","Change 75636 merged by jenkins-bot: Put edting in experimental for now https://gerrit.wikimedia.org/r/75636",task_subcomment,"Change 75636 merged by jenkins-bot: Put edting in experimental for now GERRIT_URL",ACTION ON ISSUE 253187,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","Change 75636 had a related patch set uploaded by Jforrester: Put edting in experimental for now https://gerrit.wikimedia.org/r/75636",task_subcomment,"Change 75636 had a related patch set uploaded by Jforrester: Put edting in experimental for now GERRIT_URL",ACTION ON ISSUE 253183,"VisualEditor: A on page causes ""Uncaught RangeError: Maximum call stack size exceeded"" in oojs.compare","[Sorry, somehow it was created without a description.] On the latest master I cannot edit a page that has in it. VisualEditor appears to be loading with the ""progress bar"", but doesn't go to actual editing mode. Versions: VisualEditor 393807462e9d04ec5e437cb50ef1d03e5644e9be Parsoid be8a7dea49bd70692ef574a1bb7c7a70584d77e3 core e617dc6c8f2ce1d867ddadcd4bc3de098a84ff07",task_subcomment,"[Sorry, somehow it was created without a description.] On the latest master I cannot edit a page that has in it. VisualEditor appears to be loading with the ""progress bar"", but doesn't go to actual editing mode. Versions: VisualEditor 393807462e9d04ec5e437cb50ef1d03e5644e9be Parsoid be8a7dea49bd70692ef574a1bb7c7a70584d77e3 core e617dc6c8f2ce1d867ddadcd4bc3de098a84ff07",BUG REPRODUCTION 53689,VisualEditor: Newly-added references need a page save before being reusable,"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",task_description,"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",BUG REPRODUCTION 462236,VisualEditor: Newly-added references need a page save before being reusable,This is still the case for references added inside a table though?,task_subcomment,This is still the case for references added inside a table though?,BUG REPRODUCTION 238135,VisualEditor: Newly-added references need a page save before being reusable,"Change 81964 merged by jenkins-bot: Re-build reference search index so they can be used mid-edit https://gerrit.wikimedia.org/r/81964",task_subcomment,"Change 81964 merged by jenkins-bot: Re-build reference search index so they can be used mid-edit GERRIT_URL",ACTION ON ISSUE 238133,VisualEditor: Newly-added references need a page save before being reusable,Now fixed in master and will be deployed next week.,task_subcomment,Now fixed in master and will be deployed next week.,TASK PROGRESS 238131,VisualEditor: Newly-added references need a page save before being reusable,"Change 81964 had a related patch set uploaded by Trevor Parscal: Bug 52000 - Reusing new reference groups https://gerrit.wikimedia.org/r/81964",task_subcomment,"Change 81964 had a related patch set uploaded by Trevor Parscal: Bug 52000 - Reusing new reference groups GERRIT_URL",SOLUTION USAGE 238127,VisualEditor: Newly-added references need a page save before being reusable,"So bug reports are taking 2 weeks to be assessed and assigned? That sounds like bad news. Glad to see it's now ""highest"", thanks. I'm amazed it took so long to be reported as a bug, and suspect it's because the experience of adding refs has been so dreadful that people haven't picked up on this specific aspect to report as a distinctive bug. Good luck.",task_subcomment,"So bug reports are taking 2 weeks to be assessed and assigned? That sounds like bad news. Glad to see it's now ""highest"", thanks. I'm amazed it took so long to be reported as a bug, and suspect it's because the experience of adding refs has been so dreadful that people haven't picked up on this specific aspect to report as a distinctive bug. Good luck.",ACTION ON ISSUE 238122,VisualEditor: Newly-added references need a page save before being reusable,"(In reply to comment #2) > I can think of possible two reasons why this bug has not been given high > priority: You forgot option 3: We hadn't got to this bug report yet (aka, ""AGF""). :-) Now marked appropriately.",task_subcomment,"(In reply to comment #2) QUOTE QUOTE You forgot option 3: We hadn't got to this bug report yet (aka, ""AGF""). :-) Now marked appropriately.",ACTION ON ISSUE 238120,VisualEditor: Newly-added references need a page save before being reusable,"I can think of possible two reasons why this bug has not been given high priority: (1) Those unfamiliar with creating or substantially expanding Wikipedia articles don't think that this is a big deal. They are wrong - it IS a big deal. Not been able to cite the same source two or more times in an article, which is exceptionally common, causes all the problems noted by Pam, above. or (2) VE's fundamental architecture prevents it from adding footnotes created during an editing session to the list of footnotes that existed prior to that session, and if this were listed as a high-priority bug, that design mistake might be much more obvious. I really, really hope that the answer is not (2), because if so, that's a deal-breaker. The lack of such functionality is certainly, in and of itself, reason to NOW recommend that anyone writing a new article *not* do so in VE. (And, no, it's not acceptable to do everything but the footnotes in VE, then do footnotes with the wikitext editor - users absolutely should be footnoting their text additions with citations, *as they go along*, if only for efficiency.)",task_subcomment,"I can think of possible two reasons why this bug has not been given high priority: (1) Those unfamiliar with creating or substantially expanding Wikipedia articles don't think that this is a big deal. They are wrong - it IS a big deal. Not been able to cite the same source two or more times in an article, which is exceptionally common, causes all the problems noted by Pam, above. or (2) VE's fundamental architecture prevents it from adding footnotes created during an editing session to the list of footnotes that existed prior to that session, and if this were listed as a high-priority bug, that design mistake might be much more obvious. I really, really hope that the answer is not (2), because if so, that's a deal-breaker. The lack of such functionality is certainly, in and of itself, reason to NOW recommend that anyone writing a new article *not* do so in VE. (And, no, it's not acceptable to do everything but the footnotes in VE, then do footnotes with the wikitext editor - users absolutely should be footnoting their text additions with citations, *as they go along*, if only for efficiency.)",SOLUTION DISCUSSION 238115,VisualEditor: Newly-added references need a page save before being reusable,"I'd urge this to be a higher priority: how do we expect people to create good new articles, even a well-cited stub, if they can't use the same reference for more than one point? They get offered a ""reuse a reference"" button, but it doesn't work: seriously bad news. The confused editor then has several choices: (a) don't give the extra reference(s) they think are appropriate, dumbing down the article; (b) re-input the reference each time they want to use it; (c) stop editing in VE and go into Edit Source (if they're lucky enough to be an established editor who knows about it and has learned how to use it ... not for newbies according to current ideas); (d) curse and swear and givve up trying to create their article and probably abandon editing Wikipedia altogether.",task_subcomment,"I'd urge this to be a higher priority: how do we expect people to create good new articles, even a well-cited stub, if they can't use the same reference for more than one point? They get offered a ""reuse a reference"" button, but it doesn't work: seriously bad news. The confused editor then has several choices: (a) don't give the extra reference(s) they think are appropriate, dumbing down the article; (b) re-input the reference each time they want to use it; (c) stop editing in VE and go into Edit Source (if they're lucky enough to be an established editor who knows about it and has learned how to use it ... not for newbies according to current ideas); (d) curse and swear and givve up trying to create their article and probably abandon editing Wikipedia altogether.",SOLUTION DISCUSSION 53152,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,"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",task_description,"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",SOLUTION DISCUSSION 231609,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,This was done and deployed last week.,task_subcomment,This was done and deployed last week.,TASK PROGRESS 231603,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,"Change 74191 merged by jenkins-bot: Reference dialog commingling https://gerrit.wikimedia.org/r/74191",task_subcomment,"Change 74191 merged by jenkins-bot: Reference dialog commingling GERRIT_URL",ACTION ON ISSUE 231598,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,"Change 74191 had a related patch set uploaded by Jforrester: Reference dialog commingling https://gerrit.wikimedia.org/r/74191",task_subcomment,"Change 74191 had a related patch set uploaded by Jforrester: Reference dialog commingling GERRIT_URL",SOLUTION USAGE 231594,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,"Change 74191 had a related patch set uploaded by Trevor Parscal: Reference dialog commingling https://gerrit.wikimedia.org/r/74191",task_subcomment,"Change 74191 had a related patch set uploaded by Trevor Parscal: Reference dialog commingling GERRIT_URL",SOLUTION USAGE 231591,VisualEditor: Refactor references dialog to allow immediate insertion of reference content,"James and I agreed to make this a ""stretch blocker"" for the IP release. (That means it's a blocker for now, unless other issues around content corruption or the basic edit surfacing operation become more critical.) The reason is that citations are such a crucial part of the new editing experience that we'd really like to make some basic improvements to the dialog ASAP, ahead of additional refactoring work around supporting citation templates etc.",task_subcomment,"James and I agreed to make this a ""stretch blocker"" for the IP release. (That means it's a blocker for now, unless other issues around content corruption or the basic edit surfacing operation become more critical.) The reason is that citations are such a crucial part of the new editing experience that we'd really like to make some basic improvements to the dialog ASAP, ahead of additional refactoring work around supporting citation templates etc.",SOLUTION DISCUSSION 53150,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"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",task_description,"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",BUG REPRODUCTION 343127,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 180240 merged by jenkins-bot: Remove workaround for Visual Editor bug (T53150). [[https://gerrit.wikimedia.org/r/180240]]",task_subcomment,"Change 180240 merged by jenkins-bot: Remove workaround for Visual Editor bug (T53150). [[GERRIT_URL]]",ACTION ON ISSUE 343046,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 180240 had a related patch set uploaded (by Cscott): Remove workaround for Visual Editor bug (T53150). [[https://gerrit.wikimedia.org/r/180240]] #patch-for-review",task_subcomment,"Change 180240 had a related patch set uploaded (by Cscott): Remove workaround for Visual Editor bug (T53150). [[GERRIT_URL]] #patch-for-review",ACTION ON ISSUE 231507,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"We've not seen this recur; it was probably caused by mis-cached code. Closing, but please re-open if it does happen again.",task_subcomment,"We've not seen this recur; it was probably caused by mis-cached code. Closing, but please re-open if it does happen again.",ACTION ON ISSUE 231502,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"**wicke** wrote: %%%*** Bug 51175 has been marked as a duplicate of this bug. ***%%%",task_subcomment,"**wicke** wrote: %%%*** Bug 51175 has been marked as a duplicate of this bug. ***%%%",ACTION ON ISSUE 231496,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"(In reply to comment #16) > (In reply to comment #15) > > I'm assuming that this is not yet deployed, as a new report was added to > > 51161: > > > It is deployed. > > > Normally this single-transclusion content should be covered by the Parsoid > > workaround. Did anything change in the VE handling recently that could have > > re-added the ""i"" property with a faulty value? > That sounds unlikely. When the user adds a new parameter, that parameter > won't > have an i value, but that seems reasonable to me. That infobox already existed. The 'i' property is per transclusion, not per parameter.",task_subcomment,"(In reply to comment #16) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE That infobox already existed. The 'i' property is per transclusion, not per parameter.",SOLUTION DISCUSSION 231489,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"(In reply to comment #15) > I'm assuming that this is not yet deployed, as a new report was added to > 51161: > It is deployed. > Normally this single-transclusion content should be covered by the Parsoid > workaround. Did anything change in the VE handling recently that could have > re-added the ""i"" property with a faulty value? That sounds unlikely. When the user adds a new parameter, that parameter won't have an i value, but that seems reasonable to me. I'll try to reproduce this later and see what's being sent back to Parsoid.",task_subcomment,"(In reply to comment #15) QUOTE QUOTE QUOTE It is deployed. QUOTE QUOTE QUOTE That sounds unlikely. When the user adds a new parameter, that parameter won't have an i value, but that seems reasonable to me. I'll try to reproduce this later and see what's being sent back to Parsoid.",MOTIVATION 231485,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"I'm assuming that this is not yet deployed, as a new report was added to 51161: --------------------------------------------------- This is what happened: http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=next&oldid=557856562 This is what the user intended: http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=564074475&oldid=557856562 If removal of newlines really is necessary, please insert a space instead. If that is not possible, please remove the spaces from both sides of each equals. An arrangement like |name = Scarborough|symbol = rail|code = SCA|image_name = ScarboroughRailwayStation.jpg|caption = The entrance to the station gives the impression of associating a parameter name with the value immediately preceding. An arrangement like |name=Scarborough |symbol=rail |code=SCA |image_name=ScarboroughRailwayStation.jpg |caption=The entrance to the station would associate a parameter name with the value immediately following. ------------------------------------------------- Normally this single-transclusion content should be covered by the Parsoid workaround. Did anything change in the VE handling recently that could have re-added the ""i"" property with a faulty value?",task_subcomment,"I'm assuming that this is not yet deployed, as a new report was added to 51161: --------------------------------------------------- This is what happened: URL This is what the user intended: URL If removal of newlines really is necessary, please insert a space instead. If that is not possible, please remove the spaces from both sides of each equals. An arrangement like |name = Scarborough|symbol = rail|code = SCA|image_name = ScarboroughRailwayStation.jpg|caption = The entrance to the station gives the impression of associating a parameter name with the value immediately preceding. An arrangement like |name=Scarborough |symbol=rail |code=SCA |image_name=ScarboroughRailwayStation.jpg |caption=The entrance to the station would associate a parameter name with the value immediately following. ------------------------------------------------- Normally this single-transclusion content should be covered by the Parsoid workaround. Did anything change in the VE handling recently that could have re-added the ""i"" property with a faulty value?",SOLUTION DISCUSSION 231479,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,*** Bug 51161 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51161 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 231473,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 73372 merged by jenkins-bot: Preserve unused Parsoid template properties https://gerrit.wikimedia.org/r/73372",task_subcomment,"Change 73372 merged by jenkins-bot: Preserve unused Parsoid template properties GERRIT_URL",ACTION ON ISSUE 231467,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 73372 had a related patch set uploaded by Catrope: Preserve unused Parsoid template properties https://gerrit.wikimedia.org/r/73372",task_subcomment,"Change 73372 had a related patch set uploaded by Catrope: Preserve unused Parsoid template properties GERRIT_URL",ACTION ON ISSUE 231460,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"The Parsoid workaround above is now deployed. If the index went missing in VE, it assumes that a single-transclusion target was not swapped out and reinserts the lost index in that case. This should avoid corruptions in the common single-template case. It will do nothing for multi-transclusion content (table start / row etc), and will also fail if the template was swapped out for another one. The latter case should be rare.",task_subcomment,"The Parsoid workaround above is now deployed. If the index went missing in VE, it assumes that a single-transclusion target was not swapped out and reinserts the lost index in that case. This should avoid corruptions in the common single-template case. It will do nothing for multi-transclusion content (table start / row etc), and will also fail if the template was swapped out for another one. The latter case should be rare.",SOLUTION USAGE 231453,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 73187 merged by jenkins-bot: Workaround for VE bug 51150 https://gerrit.wikimedia.org/r/73187",task_subcomment,"Change 73187 merged by jenkins-bot: Workaround for VE bug 51150 GERRIT_URL",ACTION ON ISSUE 231446,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Change 73187 had a related patch set uploaded by GWicke: Workaround for VE bug 51150 https://gerrit.wikimedia.org/r/73187",task_subcomment,"Change 73187 had a related patch set uploaded by GWicke: Workaround for VE bug 51150 GERRIT_URL",SOLUTION USAGE 231438,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"Example on http://www.mediawiki.org/wiki/User:GWicke/TestDataMW?veaction=edit: Original data-mw: data-mw='{""target"":{""wt"":""echo"",""href"":""../Template:Echo""},""params"":{""1"":{""wt"":""foo""}},""i"":0}' data-mw through VE without edit: data-mw=""{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"foo"}},"i":0}"" data-mw through VE after changing 'foo' to 'bar': data-mw=""{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"bar"}}}"" Note that the ""i"" member is gone.",task_subcomment,"Example on URL Original data-mw: data-mw='{""target"":{""wt"":""echo"",""href"":""../Template:Echo""},""params"":{""1"":{""wt"":""foo""}},""i"":0}' data-mw through VE without edit: data-mw=""{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"foo"}},"i":0}"" data-mw through VE after changing 'foo' to 'bar': data-mw=""{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"bar"}}}"" Note that the ""i"" member is gone.",BUG REPRODUCTION 231433,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,Aha. Gotcha.,task_subcomment,Aha. Gotcha.,ACTION ON ISSUE 231428,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"(In reply to comment #4) > https://en.wikipedia.org/w/index.php?title=Christchurch, > _Dorset&diff=prev&oldid=563716751 > appears to be a pre-deployment occurrence. This is post-Parsoid deployment.",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE This is post-Parsoid deployment.",ACTION ON ISSUE 231423,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"It is either data-mw.i or data-mw.parts[].i for templates. It is not new, but so far we have not used that information that heavily, so the fact that you drop the i probably fell under the radar. We use it to associate the public entry with private round-trip information such as the order of parameters and (crucially for this bug) whitespace. echo -e '{{echo|a = foo\n|b = c}}| node parse

{{{1}}}

",task_subcomment,"It is either data-mw.i or data-mw.parts[].i for templates. It is not new, but so far we have not used that information that heavily, so the fact that you drop the i probably fell under the radar. We use it to associate the public entry with private round-trip information such as the order of parameters and (crucially for this bug) whitespace. echo -e '{{echo|a = foo\n|b = c}}| node parse

{{{1}}}

",SOLUTION DISCUSSION 231419,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"https://en.wikipedia.org/w/index.php?title=Christchurch,_Dorset&diff=prev&oldid=563716751 appears to be a pre-deployment occurrence.",task_subcomment,URL appears to be a pre-deployment occurrence.,BUG REPRODUCTION 231415,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,*** Bug 51161 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51161 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 231410,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,"I can't reproduce this, even if I edit the template. VE preserves unmodified data-mw attributes always. Also, what is data-mw.i ? Is it new?",task_subcomment,"I can't reproduce this, even if I edit the template. VE preserves unmodified data-mw attributes always. Also, what is data-mw.i ? Is it new?",BUG REPRODUCTION 231407,VisualEditor: Preserve unmodified data-mw attributes to avoid corrupting templates' whitespace,This then causes diffs like http://en.wikipedia.org/w/index.php?title=Bj%C3%B6rk&diff=563745216&oldid=563123196,task_subcomment,This then causes diffs like URL,BUG REPRODUCTION 52848,VisualEditor/Parsoid: Beta release to en.wp IP users - blocking issues (tracking),"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",task_description,"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",ISSUE CONTENT MANAGEMENT 513031,VisualEditor/Parsoid: Beta release to en.wp IP users - blocking issues (tracking),[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366],task_subcomment,[adding the #tracking project to tasks blocking (now deprecated) T4007 as part of T93366],ACTION ON ISSUE 238714,VisualEditor/Parsoid: Beta release to en.wp IP users - blocking issues (tracking),"The aspects of bug 50747 that were wanted have now been done; bug 51152 has not, but was a soft-blocker rather than a hard-blocker.",task_subcomment,"The aspects of bug 50747 that were wanted have now been done; bug 51152 has not, but was a soft-blocker rather than a hard-blocker.",SOLUTION DISCUSSION 52768,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"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",task_description,"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**: URL **See Also**: URL",SOLUTION USAGE 233895,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"Change 119913 merged by jenkins-bot: Ultra-mega-hyper-citation editing on crack https://gerrit.wikimedia.org/r/119913",task_subcomment,"Change 119913 merged by jenkins-bot: Ultra-mega-hyper-citation editing on crack GERRIT_URL",ACTION ON ISSUE 233890,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"Change 119913 had a related patch set uploaded by Jforrester: Ultra-mega-hyper-citation editing on crack https://gerrit.wikimedia.org/r/119913",task_subcomment,"Change 119913 had a related patch set uploaded by Jforrester: Ultra-mega-hyper-citation editing on crack GERRIT_URL",TASK PROGRESS 233885,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,Yes. Hopefully this will be PTR later this week.,task_subcomment,Yes. Hopefully this will be PTR later this week.,ACTION ON ISSUE 233879,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"This has been highest priority for four months now... Does that still reflect reality?",task_subcomment,"This has been highest priority for four months now... Does that still reflect reality?",PRIORITY MANAGEMENT 233871,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"The bug as was written is the highest priority enhancement in VisualEditor and we've been working on it since October. The change in title and comment 3 reflect a further ambition for this area which will be addressed once this bug is fixed, and should be split off at some point.",task_subcomment,"The bug as was written is the highest priority enhancement in VisualEditor and we've been working on it since October. The change in title and comment 3 reflect a further ambition for this area which will be addressed once this bug is fixed, and should be split off at some point.",FUTURE PLAN 233865,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"JamesF: This has been highest priority since 2013-11-08. Any news or updates here?",task_subcomment,"JamesF: This has been highest priority since 2013-11-08. Any news or updates here?",TASK PROGRESS 233861,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,*** Bug 51188 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51188 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 233857,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,"When cite web is used, webpage title, and access date should be filled automatically for 1 click web citations.",task_subcomment,"When cite web is used, webpage title, and access date should be filled automatically for 1 click web citations.",SOLUTION DISCUSSION 233852,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,*** Bug 56708 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 56708 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 233845,VisualEditor: Implement a better version of enwiki's reference pop-up for very easy reference inserting,*** Bug 56772 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 56772 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 52731,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","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}",task_description,"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}",BUG REPRODUCTION 231719,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)",Merged and will hopefully go out soon.,task_subcomment,Merged and will hopefully go out soon.,SOLUTION USAGE 231711,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Change 72069 merged by jenkins-bot: mw.ViewPageTarget.init: Move edit section to top init https://gerrit.wikimedia.org/r/72069",task_subcomment,"Change 72069 merged by jenkins-bot: mw.ViewPageTarget.init: Move edit section to top init GERRIT_URL",SOLUTION USAGE 231705,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Please consider fixing bug 50540 and maybe bug 50405, too. They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",task_subcomment,"Please consider fixing bug 50540 and maybe bug 50405, too. They are directly dependent of this change. Fixing them now once and for all will prevent further hassle with changing editsection links back-and-forth. Actually fixing bug 50540 would probably simplify code a lot and could therefore resolve bug 50405 as a side effect.",SOLUTION DISCUSSION 231701,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Change 72069 had a related patch set uploaded by Krinkle: mw.ViewPageTarget.init: Move edit section to top init. https://gerrit.wikimedia.org/r/72069",task_subcomment,"Change 72069 had a related patch set uploaded by Krinkle: mw.ViewPageTarget.init: Move edit section to top init. GERRIT_URL",SOLUTION USAGE 231697,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.",task_subcomment,"Bizarrely, the mouseover ""edit source"" links appear briefly when mousing over ""edit"" links while VE is loading a page into edit mode.",BUG REPRODUCTION 231692,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.",task_subcomment,"Bug 48429#c35 - basically, visual section editing is a seriously hard problem, and isn't on the agenda any time soon.",FUTURE PLAN 231686,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",task_subcomment,"Well, if that's the case (I haven't heard about it, but I believe you) presumably the link should be renamed to ""edit source"" to be consistent with the naming of the tabs. Otherwise, I expect quite a bit of confusion.",SOLUTION USAGE 231679,"VisualEditor: [Regression] Section edit links have reverted to the old style (source only, not expanded)","I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",task_subcomment,"I'd call this NOTABUG, since James has declared that visual section-editing won't be funded for the foreseeable future. So we now don't have an interface that claims functionality there aren't even plans to implement.",FUTURE PLAN 52715,"VisualEditor: Transclusion dialog sometimes shows items in ""Add parameter"" that are already used","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}",task_description,"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 URL 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}",BUG REPRODUCTION 255765,"VisualEditor: Transclusion dialog sometimes shows items in ""Add parameter"" that are already used",This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,task_subcomment,This is now fixed in master and we will push to production very soon. Sorry for the inconvenience.,SOLUTION USAGE 255759,"VisualEditor: Transclusion dialog sometimes shows items in ""Add parameter"" that are already used","Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010",task_subcomment,"Change 73010 merged by jenkins-bot: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",ACTION ON ISSUE 255753,"VisualEditor: Transclusion dialog sometimes shows items in ""Add parameter"" that are already used","Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace https://gerrit.wikimedia.org/r/73010",task_subcomment,"Change 73010 had a related patch set uploaded by Trevor Parscal: Retain original param names and ignore leading/trailing whitespace GERRIT_URL",TASK PROGRESS 52708,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),"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",task_description,"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",BUG REPRODUCTION 255243,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),No longer able to repro this either so closing as fixed; will reopen if I see it reappear.,task_subcomment,No longer able to repro this either so closing as fixed; will reopen if I see it reappear.,BUG REPRODUCTION 255237,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),"(In reply to comment #5) > I still saw it a couple days ago. I'll try with a clean (standard prefs) test > account later today. Did a spot-test of 100 on Firefox and another 50 in Safari, and also didn't have any issues.",task_subcomment,"(In reply to comment #5) QUOTE QUOTE Did a spot-test of 100 on Firefox and another 50 in Safari, and also didn't have any issues.",SOLUTION DISCUSSION 255230,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),I still saw it a couple days ago. I'll try with a clean (standard prefs) test account later today.,task_subcomment,I still saw it a couple days ago. I'll try with a clean (standard prefs) test account later today.,BUG REPRODUCTION 255223,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),(Though it didn't recur for me just now on a spot-test of 100 Special:Randoms.),task_subcomment,(Though it didn't recur for me just now on a spot-test of 100 Special:Randoms.),BUG REPRODUCTION 255216,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),"(In reply to comment #2) > The collapsibleTabs thing was bug 50504, and it's supposed to be fixed now. Yes, but apparently that fix of Roan's didn't fix this issue.",task_subcomment,"(In reply to comment #2) QUOTE Yes, but apparently that fix of Roan's didn't fix this issue.",SOLUTION DISCUSSION 255206,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),"The collapsibleTabs thing was bug 50504, and it's supposed to be fixed now.",task_subcomment,"The collapsibleTabs thing was bug 50504, and it's supposed to be fixed now.",BUG REPRODUCTION 255198,VisualEditor: Sometimes not correctly initialized (about 1 in 40-50 pageviews),"FYI Timo/Roan, still getting this, but no longer getting the collapsibleTabs error on the console. :P",task_subcomment,"FYI Timo/Roan, still getting this, but no longer getting the collapsibleTabs error on the console. :P",ACTION ON ISSUE 52601,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"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}",task_description,"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}",SOLUTION DISCUSSION 249025,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"**swalling** wrote: Okay, since VE implemented this in their own dialog system, instead of us doing it in GuidedTours, I'm going to go ahead and close this.",task_subcomment,"**swalling** wrote: Okay, since VE implemented this in their own dialog system, instead of us doing it in GuidedTours, I'm going to go ahead and close this.",ACTION ON ISSUE 249020,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"(In reply to comment #11) > GuidedTour support for VE is shaping up, so we're about ready to start > building this. But before we embark on this tour you've suggested, I just > wanted to confirm you're still thinking it's necessary in light of > https://gerrit.wikimedia.org/r/#/c/73569/ and bug 49820? I think we still want a GuidedTour to highlight that the user is now in VisualEditor and not the wikitext editor; a very brief one-time message of ""hey, you're in VisualEditor now - here is the user guide"" or similar should suffice.",task_subcomment,"(In reply to comment #11) QUOTE QUOTE QUOTE QUOTE I think we still want a GuidedTour to highlight that the user is now in VisualEditor and not the wikitext editor; a very brief one-time message of ""hey, you're in VisualEditor now - here is the user guide"" or similar should suffice.",SOLUTION DISCUSSION 249015,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"James - please weigh in. My take is that we still need a first-use tour. We're changing the function of the ""Edit"" link, and just giving the user the wikitext warning isn't quite sufficient in informing them about a change of this magnitude. I don't think we'll need it indefinitely, but while VE is in Beta, doing this as part of the wider language rollout will save us and the community some additional transition pain, I think.",task_subcomment,"James - please weigh in. My take is that we still need a first-use tour. We're changing the function of the ""Edit"" link, and just giving the user the wikitext warning isn't quite sufficient in informing them about a change of this magnitude. I don't think we'll need it indefinitely, but while VE is in Beta, doing this as part of the wider language rollout will save us and the community some additional transition pain, I think.",SOLUTION DISCUSSION 249007,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"**swalling** wrote: (In reply to comment #9) > Let's strike the idea of a distinction between new and experienced users for > now. Philippe and James make the good point that we can't really tell for > sure > whether a user is new, especially when editing as an IP, so in the interest > of > simplicity and consistency, I suggest we show the same message to everyone > for > a while. We can then later either turn it off completely, or show it only to > a > subset. GuidedTour support for VE is shaping up, so we're about ready to start building this. But before we embark on this tour you've suggested, I just wanted to confirm you're still thinking it's necessary in light of https://gerrit.wikimedia.org/r/#/c/73569/ and bug 49820?",task_subcomment,"**swalling** wrote: (In reply to comment #9) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE GuidedTour support for VE is shaping up, so we're about ready to start building this. But before we embark on this tour you've suggested, I just wanted to confirm you're still thinking it's necessary in light of URL and bug 49820?",ACTION ON ISSUE 249000,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"**weskaggs** wrote: I've had quite a bit of experience with things like this working on the GIMP project, and would like to try to convey a bit of ""wisdom"" that we learned the hard way. First, there are severe limits on the amount of information a new user, unfamiliar with the interface, can learn from a guided tour. A tour can give some increased sense of familiarity, but it can't give an ability to do specific tasks. Above all, a tour can't substitute for simplicity and discoverability. Second, a guided tour should never be forced on anybody. It can be offered if that can be done unobtrusively, but should never be required. Third, if a guided tour exists, it should be available on demand, and able to be repeated as often as desired. Ideally there should be some sort of ""help"" menu in the interface, offering the tour as one of the entries. Fourth, if you make a guided tour, you should consider making a video version and putting it on Youtube. That might seem like a bizarre idea, but many users are very comfortable with that format. Also I agree that there is a strong need to show a warning to users who try to enter wiki-markup directly (with a link to an extended explanation).",task_subcomment,"**weskaggs** wrote: I've had quite a bit of experience with things like this working on the GIMP project, and would like to try to convey a bit of ""wisdom"" that we learned the hard way. First, there are severe limits on the amount of information a new user, unfamiliar with the interface, can learn from a guided tour. A tour can give some increased sense of familiarity, but it can't give an ability to do specific tasks. Above all, a tour can't substitute for simplicity and discoverability. Second, a guided tour should never be forced on anybody. It can be offered if that can be done unobtrusively, but should never be required. Third, if a guided tour exists, it should be available on demand, and able to be repeated as often as desired. Ideally there should be some sort of ""help"" menu in the interface, offering the tour as one of the entries. Fourth, if you make a guided tour, you should consider making a video version and putting it on Youtube. That might seem like a bizarre idea, but many users are very comfortable with that format. Also I agree that there is a strong need to show a warning to users who try to enter wiki-markup directly (with a link to an extended explanation).",SOLUTION DISCUSSION 248992,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"Let's strike the idea of a distinction between new and experienced users for now. Philippe and James make the good point that we can't really tell for sure whether a user is new, especially when editing as an IP, so in the interest of simplicity and consistency, I suggest we show the same message to everyone for a while. We can then later either turn it off completely, or show it only to a subset.",task_subcomment,"Let's strike the idea of a distinction between new and experienced users for now. Philippe and James make the good point that we can't really tell for sure whether a user is new, especially when editing as an IP, so in the interest of simplicity and consistency, I suggest we show the same message to everyone for a while. We can then later either turn it off completely, or show it only to a subset.",SOLUTION DISCUSSION 248987,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"We'll probably set this up so it launches when they visit a VE-eligible article, unless they have a hidden preference that shows it has launched before. The role isSinglePage plays is ensuring no cookie is stored tracking their tour progress. So even if they navigate away without closing the tour, it won't show again.",task_subcomment,"We'll probably set this up so it launches when they visit a VE-eligible article, unless they have a hidden preference that shows it has launched before. The role isSinglePage plays is ensuring no cookie is stored tracking their tour progress. So even if they navigate away without closing the tour, it won't show again.",SOLUTION DISCUSSION 248981,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"**swalling** wrote: (In reply to comment #6) > I'd suggest: > > If user account was created before July 1, 2013, display the following > message > exactly once: > > - > You are using the VisualEditor, a new rich-text editing interface for > {{SITENAME}} (currently in beta). Please be aware that wiki syntax (e.g. > ""[[link to another page]]"") will not work in this editing mode. To use > the > old editing interface, click the 'Edit source' tab or section link. > - > > For extra points, the ""exactly once"" could be managed via a ""Do not show this > message again"" checkbox. But it shouldn't be handled as a notice that comes > up > every single time -- it should definitely be dismissible. > > The reason I'd like to finalize the language soon is to give us enough time > to > get translations. I think this is reasonable. Regarding showing a tour only once: I don't think we have to add an explicit checkbox to show it exactly once. Currently the default behavior is... If a user completes the tour or clicks the X to close we never show it again. So in this case, as a single step tour, clicking the ""Okay"" button or X would end the tour and it would never repeat. That is stored as a hidden preference, so it works across sessions, but not across wikis. If we really want to tie it to a single page, there is also an isSinglePage variable we can set for the tour, which means no matter what it will only appear on that one page.",task_subcomment,"**swalling** wrote: (In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE I think this is reasonable. Regarding showing a tour only once: I don't think we have to add an explicit checkbox to show it exactly once. Currently the default behavior is... If a user completes the tour or clicks the X to close we never show it again. So in this case, as a single step tour, clicking the ""Okay"" button or X would end the tour and it would never repeat. That is stored as a hidden preference, so it works across sessions, but not across wikis. If we really want to tie it to a single page, there is also an isSinglePage variable we can set for the tour, which means no matter what it will only appear on that one page.",SOLUTION DISCUSSION 248977,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"I'd suggest: If user account was created before July 1, 2013, display the following message exactly once: - You are using the VisualEditor, a new rich-text editing interface for {{SITENAME}} (currently in beta). Please be aware that wiki syntax (e.g. ""[[link to another page]]"") will not work in this editing mode. To use the old editing interface, click the 'Edit source' tab or section link. - For extra points, the ""exactly once"" could be managed via a ""Do not show this message again"" checkbox. But it shouldn't be handled as a notice that comes up every single time -- it should definitely be dismissible. The reason I'd like to finalize the language soon is to give us enough time to get translations.",task_subcomment,"I'd suggest: If user account was created before July 1, 2013, display the following message exactly once: - You are using the VisualEditor, a new rich-text editing interface for {{SITENAME}} (currently in beta). Please be aware that wiki syntax (e.g. ""[[link to another page]]"") will not work in this editing mode. To use the old editing interface, click the 'Edit source' tab or section link. - For extra points, the ""exactly once"" could be managed via a ""Do not show this message again"" checkbox. But it shouldn't be handled as a notice that comes up every single time -- it should definitely be dismissible. The reason I'd like to finalize the language soon is to give us enough time to get translations.",SOLUTION DISCUSSION 248972,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"(In reply to comment #2) > (In reply to comment #1) > > Adding Steven in case his team wants to help/weigh in. > > TL;DR: > > Unless VE team wants to own it, I think E3 can handle any tours of basic > editing functionality (with and without VE). What we have is 1/2 way toward > the changes Erik requested. Awesome; very happy for E3 to lead on this. We'll support as needed, of course. > We are working on adding better VE support in GuidedTour currently, and I've > added Matt Flaschen since he's tackling that. We are shooting for feature > parity with our previous guided tour of editing for the first time delivered > to GettingStarted editors, with the exception being that there is no Preview > step to point to in VE. > > Also, soon we hope to test delivering a guided tour to all newly-registered > editors, outside the GettingStarted funnel. (Docs: > https://meta.wikimedia.org/wiki/Research:Guided_tours). Whether we run that > test on a wiki like Spanish or French instead of English depends on l10n of > the ""first edit"" tour and whether VE support is ready. S Page is helping > out with this test, so I've added him as well. > > If we're interested in pointing out the difference between VE and wikitext to > users right away, we could easily build that in as step for the guided tours > delivered via GettingStarted and the general ""first edit"" tour we're > planning. Currently with the tour that's in production, we just point to the > Edit button and section edit buttons. > > I'm open to changing that, but I do think we should be cautious about > throwing too much complexity at first time editors too soon, by pointing out > the multiple methods of editing. I added Pau for his input. Yeah, I'm not convinced I know what we'd want to do. Maybe just a simple ""you're using VisualEditor"" on first load for experienced users? Maybe a set of ""add a {reference,template} by clicking here"" ones too? Maybe not? What do you advise?",task_subcomment,"(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Awesome; very happy for E3 to lead on this. We'll support as needed, of course. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Yeah, I'm not convinced I know what we'd want to do. Maybe just a simple ""you're using VisualEditor"" on first load for experienced users? Maybe a set of ""add a {reference,template} by clicking here"" ones too? Maybe not? What do you advise?",ACTION ON ISSUE 248968,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"If it's semi-experienced users who are entering the wikitext, that could be improved with a tour specific to them (and/or VE documentation). If it's new users (they are less likely to know wikitext, though) making this mistake, maybe the comparison is necessary.",task_subcomment,"If it's semi-experienced users who are entering the wikitext, that could be improved with a tour specific to them (and/or VE documentation). If it's new users (they are less likely to know wikitext, though) making this mistake, maybe the comparison is necessary.",SOLUTION DISCUSSION 248964,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"(In reply to comment #2) > If we're interested in pointing out the difference between VE and wikitext to > users right away, we could easily build that in as step for the guided tours > delivered via GettingStarted and the general ""first edit"" tour we're > planning. I don't think that (comparing VE and wikitext) needs to be in the first tour. It's discoverable in the UI in a consistent way, plus people on-wiki will point to and explain the difference when necessary.",task_subcomment,"(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE I don't think that (comparing VE and wikitext) needs to be in the first tour. It's discoverable in the UI in a consistent way, plus people on-wiki will point to and explain the difference when necessary.",SOLUTION DISCUSSION 248961,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),"**swalling** wrote: (In reply to comment #1) > Adding Steven in case his team wants to help/weigh in. TL;DR: Unless VE team wants to own it, I think E3 can handle any tours of basic editing functionality (with and without VE). What we have is 1/2 way toward the changes Erik requested. Full details: We are working on adding better VE support in GuidedTour currently, and I've added Matt Flaschen since he's tackling that. We are shooting for feature parity with our previous guided tour of editing for the first time delivered to GettingStarted editors, with the exception being that there is no Preview step to point to in VE. Also, soon we hope to test delivering a guided tour to all newly-registered editors, outside the GettingStarted funnel. (Docs: https://meta.wikimedia.org/wiki/Research:Guided_tours). Whether we run that test on a wiki like Spanish or French instead of English depends on l10n of the ""first edit"" tour and whether VE support is ready. S Page is helping out with this test, so I've added him as well. If we're interested in pointing out the difference between VE and wikitext to users right away, we could easily build that in as step for the guided tours delivered via GettingStarted and the general ""first edit"" tour we're planning. Currently with the tour that's in production, we just point to the Edit button and section edit buttons. I'm open to changing that, but I do think we should be cautious about throwing too much complexity at first time editors too soon, by pointing out the multiple methods of editing. I added Pau for his input.",task_subcomment,"**swalling** wrote: (In reply to comment #1) QUOTE TL;DR: Unless VE team wants to own it, I think E3 can handle any tours of basic editing functionality (with and without VE). What we have is 1/2 way toward the changes Erik requested. Full details: We are working on adding better VE support in GuidedTour currently, and I've added Matt Flaschen since he's tackling that. We are shooting for feature parity with our previous guided tour of editing for the first time delivered to GettingStarted editors, with the exception being that there is no Preview step to point to in VE. Also, soon we hope to test delivering a guided tour to all newly-registered editors, outside the GettingStarted funnel. (Docs: URL Whether we run that test on a wiki like Spanish or French instead of English depends on l10n of the ""first edit"" tour and whether VE support is ready. S Page is helping out with this test, so I've added him as well. If we're interested in pointing out the difference between VE and wikitext to users right away, we could easily build that in as step for the guided tours delivered via GettingStarted and the general ""first edit"" tour we're planning. Currently with the tour that's in production, we just point to the Edit button and section edit buttons. I'm open to changing that, but I do think we should be cautious about throwing too much complexity at first time editors too soon, by pointing out the multiple methods of editing. I added Pau for his input.",SOLUTION DISCUSSION 248956,VisualEditor: Provide a GuidedTour for first-time VisualEditor users (ones for both newbies for and experienced editors?),Adding Steven in case his team wants to help/weigh in.,task_subcomment,Adding Steven in case his team wants to help/weigh in.,ACTION ON ISSUE 52441,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"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",task_description,"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**: URL",BUG REPRODUCTION 239595,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"This is now deployed and appears to be working as expected in production, according to my testing. Marking as fixed. Please re-open if you find otherwise.",task_subcomment,"This is now deployed and appears to be working as expected in production, according to my testing. Marking as fixed. Please re-open if you find otherwise.",ACTION ON ISSUE 239592,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Change 72070 merged by jenkins-bot: mw.ViewPageTarget: Fix incorrect retention of the wrong oldid https://gerrit.wikimedia.org/r/72070",task_subcomment,"Change 72070 merged by jenkins-bot: mw.ViewPageTarget: Fix incorrect retention of the wrong oldid GERRIT_URL",SOLUTION USAGE 239587,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),*** Bug 50596 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50596 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 239580,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),Bug 47420 is the same thing that was reopened. One of these two should be merged as a duplicate of the other.,task_subcomment,Bug 47420 is the same thing that was reopened. One of these two should be merged as a duplicate of the other.,TASK PROGRESS 239572,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Change 72070 had a related patch set uploaded by Krinkle: mw.ViewPageTarget: Only pass oldid if we have to and clear/update it on save https://gerrit.wikimedia.org/r/72070",task_subcomment,"Change 72070 had a related patch set uploaded by Krinkle: mw.ViewPageTarget: Only pass oldid if we have to and clear/update it on save GERRIT_URL",SOLUTION USAGE 239565,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Actually, though we are indeed initialising for the version the user is reading instead of the latest version (separate bug) we do update `this.oldid` in mw.ViewPageTarget#onSave based on the data we got from the API. However the API isn't returning that data, there is no ""data.newrevid"" returned by ApiVisualEditor.",task_subcomment,"Actually, though we are indeed initialising for the version the user is reading instead of the latest version (separate bug) we do update CODE in mw.ViewPageTarget#onSave based on the data we got from the API. However the API isn't returning that data, there is no ""data.newrevid"" returned by ApiVisualEditor.",BUG REPRODUCTION 239559,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Which makes me wonder, why are we using that in the first place. Don't we always want to be editing the latest version (except when url has oldid=) even if the latest version is more recent than the version the user is reading (either because the page is cached or because an edit was made while the user was viewing the page).",task_subcomment,"Which makes me wonder, why are we using that in the first place. Don't we always want to be editing the latest version (except when url has oldid=) even if the latest version is more recent than the version the user is reading (either because the page is cached or because an edit was made while the user was viewing the page).",SOLUTION DISCUSSION 239552,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Figured out the cause: This revision id for the page is initialised in ve.init.mw.Target from wgCurRevisionId but then never updated.",task_subcomment,"Figured out the cause: This revision id for the page is initialised in ve.init.mw.Target from wgCurRevisionId but then never updated.",SOLUTION DISCUSSION 239546,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"(In reply to comment #8) > If there's any likely timescale for the fixing of this bug, it might be > useful to comment there: is ""soon"" likely to be hours, days, or weeks?! Days. :-) Don't want to promise ""tomorrow"" if we don't manage to fix it by then, but certainly as soon as we can get it written, tested and deployed.",task_subcomment,"(In reply to comment #8) QUOTE QUOTE Days. :-) Don't want to promise ""tomorrow"" if we don't manage to fix it by then, but certainly as soon as we can get it written, tested and deployed.",SOLUTION DISCUSSION 239539,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"(In reply to comment #7) > (In reply to comment #6) > > Pending a full solution, is there any way that the pink error box can be > > amended to include something like: ""Please click the ""Cancel"" button, then > > Refresh/Reload the page and try again. Apologies for this temporary problem - > > we are working on it."" > > > > It's irritating for an experienced editor who has found the work-round, but > > must be desperately confusing for a new editor who has just made an edit, had > > an afterthought, and gets that message. > > The message displayed is editable by any English Wikipedia sysop; this > doesn't > need any code changes to alter the text, or remove the bright pinkness, but > you > should discuss it with the community: > https://en.wikipedia.org/wiki/MediaWiki:Editingold > > We're hoping to get this regression fixed soon; sorry for the inconvenience. OK, have raised a suggestion at [[MediaWiki_talk:Editingold#VE_problem]]. If there's any likely timescale for the fixing of this bug, it might be useful to comment there: is ""soon"" likely to be hours, days, or weeks?!",task_subcomment,"(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE OK, have raised a suggestion at [[MediaWiki_talk:Editingold#VE_problem]]. If there's any likely timescale for the fixing of this bug, it might be useful to comment there: is ""soon"" likely to be hours, days, or weeks?!",ACTION ON ISSUE 239534,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"(In reply to comment #6) > Pending a full solution, is there any way that the pink error box can be > amended to include something like: ""Please click the ""Cancel"" button, then > Refresh/Reload the page and try again. Apologies for this temporary problem - > we are working on it."" > > It's irritating for an experienced editor who has found the work-round, but > must be desperately confusing for a new editor who has just made an edit, had > an afterthought, and gets that message. The message displayed is editable by any English Wikipedia sysop; this doesn't need any code changes to alter the text, or remove the bright pinkness, but you should discuss it with the community: https://en.wikipedia.org/wiki/MediaWiki:Editingold We're hoping to get this regression fixed soon; sorry for the inconvenience.",task_subcomment,"(In reply to comment #6) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE The message displayed is editable by any English Wikipedia sysop; this doesn't need any code changes to alter the text, or remove the bright pinkness, but you should discuss it with the community: URL We're hoping to get this regression fixed soon; sorry for the inconvenience.",ACTION ON ISSUE 239529,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Pending a full solution, is there any way that the pink error box can be amended to include something like: ""Please click the ""Cancel"" button, then Refresh/Reload the page and try again. Apologies for this temporary problem - we are working on it."" It's irritating for an experienced editor who has found the work-round, but must be desperately confusing for a new editor who has just made an edit, had an afterthought, and gets that message.",task_subcomment,"Pending a full solution, is there any way that the pink error box can be amended to include something like: ""Please click the ""Cancel"" button, then Refresh/Reload the page and try again. Apologies for this temporary problem - we are working on it."" It's irritating for an experienced editor who has found the work-round, but must be desperately confusing for a new editor who has just made an edit, had an afterthought, and gets that message.",WORKAROUNDS 239524,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),*** Bug 50555 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50555 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 239521,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Comment on attachment 12694 Screen recording of the bug This is how the problem materialize for me, as you see, it jumps back to the previous revision on edit, and then complains it's not the latest revision.",task_subcomment,"Comment on attachment 12694 Screen recording of the bug This is how the problem materialize for me, as you see, it jumps back to the previous revision on edit, and then complains it's not the latest revision.",BUG REPRODUCTION 239519,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"Screen recording of the bug **Attached**: {F11340}",task_subcomment,"Screen recording of the bug **Attached**: {F11340}",SOLUTION USAGE 239515,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"The url is http://en.wikipedia.beta.wmflabs.org/wiki/User:AzaToth/Test2?veaction=edit Following is a timeline: http://i.imgur.com/VmbT33s.png http://i.imgur.com/FVWEf4r.png http://i.imgur.com/ieTdi36.png http://i.imgur.com/DP0eDLs.png http://i.imgur.com/fNRbqeP.png",task_subcomment,"The url is URL Following is a timeline: URL URL URL URL URL",SOLUTION DISCUSSION 239511,VisualEditor: [Regression] Edit tab points to the oldid not the newid when saving (except for when creating pages),"What url do you go to initially? After saving and reading the page, what do you see. The version from before you edited or after, and what does the url look like? When going into edit mode after saving, what does the url look like?",task_subcomment,"What url do you go to initially? After saving and reading the page, what do you see. The version from before you edited or after, and what does the url look like? When going into edit mode after saving, what does the url look like?",INVESTIGATION AND EXPLORATION 52424,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","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",task_description,"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**: URL",BUG REPRODUCTION 238349,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","This is now fixed in master, which will be deployed within the hour.",task_subcomment,"This is now fixed in master, which will be deployed within the hour.",SOLUTION USAGE 238342,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73446 merged by jenkins-bot: mw.ViewPageTarget: Refetch token if session expired https://gerrit.wikimedia.org/r/73446",task_subcomment,"Change 73446 merged by jenkins-bot: mw.ViewPageTarget: Refetch token if session expired GERRIT_URL",SOLUTION USAGE 238336,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Please note that the reporter of Bug 51302 also points out that the session expiry clock already starts ticking once an article is opened for *reading*, i.e. potentially much earlier than when the visual editor is started on the article.",task_subcomment,"Please note that the reporter of Bug 51302 also points out that the session expiry clock already starts ticking once an article is opened for *reading*, i.e. potentially much earlier than when the visual editor is started on the article.",SOLUTION DISCUSSION 238331,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work",I just encountered this problem. I would call this bug a blocker as it is effectively 'dataloss' in bmo keyword terminology!,task_subcomment,I just encountered this problem. I would call this bug a blocker as it is effectively 'dataloss' in bmo keyword terminology!,BUG REPRODUCTION 238326,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work",*** Bug 51302 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51302 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 238319,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73446 had a related patch set uploaded by Krinkle: (DRAFT) mw.ViewPageTarget: Refetch token if session expired https://gerrit.wikimedia.org/r/73446",task_subcomment,"Change 73446 had a related patch set uploaded by Krinkle: (DRAFT) mw.ViewPageTarget: Refetch token if session expired GERRIT_URL",ACTION ON ISSUE 238314,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73203 merged by jenkins-bot: mw.ViewPageTarget: Improve error message for badtoken error https://gerrit.wikimedia.org/r/73203",task_subcomment,"Change 73203 merged by jenkins-bot: mw.ViewPageTarget: Improve error message for badtoken error GERRIT_URL",ACTION ON ISSUE 238309,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73189 merged by jenkins-bot: api: Split save action into separate API module https://gerrit.wikimedia.org/r/73189",task_subcomment,"Change 73189 merged by jenkins-bot: api: Split save action into separate API module GERRIT_URL",ACTION ON ISSUE 238305,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73203 had a related patch set uploaded by Krinkle: mw.ViewPageTarget: Improve error message for badtoken error https://gerrit.wikimedia.org/r/73203",task_subcomment,"Change 73203 had a related patch set uploaded by Krinkle: mw.ViewPageTarget: Improve error message for badtoken error GERRIT_URL",SOLUTION USAGE 238301,"VisualEditor: ""Invalid token"" message after period of inactivity leads to lost work","Change 73189 had a related patch set uploaded by Krinkle: API: Split save action into separate API module https://gerrit.wikimedia.org/r/73189",task_subcomment,"Change 73189 had a related patch set uploaded by Krinkle: API: Split save action into separate API module GERRIT_URL",ACTION ON ISSUE 52423,"VisualEditor: ref warning appears within template that contains references, post-modification","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 , 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}",task_description,"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 , can't find a tag in the template itself, and freaks the heck out. -------------------------- **Version**: unspecified **Severity**: minor **See Also**: URL **Attached**: {F11303}",MOTIVATION 238262,"VisualEditor: ref warning appears within template that contains references, post-modification",I'm forking this off into bug 51337.,task_subcomment,I'm forking this off into bug 51337.,TASK PROGRESS 238260,"VisualEditor: ref warning appears within template that contains references, post-modification","Change 73614 had a related patch set uploaded by Esanders: Use new class to detect Cite errors inside templates https://gerrit.wikimedia.org/r/73614",task_subcomment,"Change 73614 had a related patch set uploaded by Esanders: Use new class to detect Cite errors inside templates GERRIT_URL",TASK PROGRESS 238257,"VisualEditor: ref warning appears within template that contains references, post-modification",Should probably leave this open to track improvements.,task_subcomment,Should probably leave this open to track improvements.,FUTURE PLAN 238252,"VisualEditor: ref warning appears within template that contains references, post-modification",Also: https://gerrit.wikimedia.org/r/73096,task_subcomment,Also: GERRIT_URL,ACTION ON ISSUE 238247,"VisualEditor: ref warning appears within template that contains references, post-modification","These are now hidden by the above commit, which we're deploying in the next few minutes.",task_subcomment,"These are now hidden by the above commit, which we're deploying in the next few minutes.",ACTION ON ISSUE 238241,"VisualEditor: ref warning appears within template that contains references, post-modification","Change 73092 merged by jenkins-bot: Hide ref errors inside MW transclusions https://gerrit.wikimedia.org/r/73092",task_subcomment,"Change 73092 merged by jenkins-bot: Hide ref errors inside MW transclusions GERRIT_URL",ACTION ON ISSUE 238235,"VisualEditor: ref warning appears within template that contains references, post-modification","Change 73092 had a related patch set uploaded by Esanders: Hide ref errors inside MW transclusions https://gerrit.wikimedia.org/r/73092",task_subcomment,"Change 73092 had a related patch set uploaded by Esanders: Hide ref errors inside MW transclusions GERRIT_URL",TASK PROGRESS 238227,"VisualEditor: ref warning appears within template that contains references, post-modification","The short-term fix is to just strip this comment from the returned HTML that the PHP parser gives us. When we switch over to using Parsoid for this, we'll need that to run in context, somehow, so the references are correctly numbered and that we know to update the relevant reference lists.",task_subcomment,"The short-term fix is to just strip this comment from the returned HTML that the PHP parser gives us. When we switch over to using Parsoid for this, we'll need that to run in context, somehow, so the references are correctly numbered and that we know to update the relevant reference lists.",SOLUTION DISCUSSION 52349,VisualEditor: Reference toolbar icon missing in wmf9,"The references list one is still there; did Trevor's change break it? -------------------------- **Version**: unspecified **Severity**: critical",task_description,"The references list one is still there; did Trevor's change break it? -------------------------- **Version**: unspecified **Severity**: critical",BUG REPRODUCTION 233797,VisualEditor: Reference toolbar icon missing in wmf9,Fixed with new pull.,task_subcomment,Fixed with new pull.,SOLUTION USAGE 52339,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,"http://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FGNoSR&diff=561873747&oldid=561873385 Removes non-breaking space. -------------------------- **Version**: unspecified **Severity**: major",task_description,"URL Removes non-breaking space. -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 233191,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,"We cannot reproduce this on several different browsers/computers; it's most likely cause by a browser plug-in that the user has installed. Marking as ""WORKSFORME"" but if you can work out with the user what they have that is breaking VisualEditor it'd be good to know.",task_subcomment,"We cannot reproduce this on several different browsers/computers; it's most likely cause by a browser plug-in that the user has installed. Marking as ""WORKSFORME"" but if you can work out with the user what they have that is breaking VisualEditor it'd be good to know.",WORKAROUNDS 233185,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,Chrome Version 27.0.1453.116 on Windows 7 Home Premium.,task_subcomment,Chrome Version 27.0.1453.116 on Windows 7 Home Premium.,BUG REPRODUCTION 233178,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,Will inquire.,task_subcomment,Will inquire.,ACTION ON ISSUE 233171,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,Do you know which browser was used for this edit?,task_subcomment,Do you know which browser was used for this edit?,ACTION ON ISSUE 233164,VisualEditor:  s converted to space characters (32s not 160s) on round-trip,Odd. I can't reproduce this locally or on the article.,task_subcomment,Odd. I can't reproduce this locally or on the article.,BUG REPRODUCTION 52264,load.php error? many symptoms...,"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",task_description,"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",BUG REPRODUCTION 254099,load.php error? many symptoms...,Ah it seems the cached load.php got cleared finally. I got AFT and VisualEdit working properly now :-],task_subcomment,Ah it seems the cached load.php got cleared finally. I got AFT and VisualEdit working properly now :-],TASK PROGRESS 254093,load.php error? many symptoms...,"AFT, VisualEditor are now working when passing ?debug=true to the URL (which bypass resourceloader cache). I have no idea how to clear the resource loader cache though :(",task_subcomment,"AFT, VisualEditor are now working when passing ?debug=true to the URL (which bypass resourceloader cache). I have no idea how to clear the resource loader cache though :(",SOLUTION USAGE 254086,load.php error? many symptoms...,Changes above reverts the two patches mentionned in bug 45918.,task_subcomment,Changes above reverts the two patches mentionned in bug 45918.,SOLUTION DISCUSSION 254080,load.php error? many symptoms...,Related URL: https://gerrit.wikimedia.org/r/70806 (Gerrit Change Ie373d1f407788a8e2456c3d8a34cc79ac9ed8bb6),task_subcomment,Related URL: GERRIT_URL (Gerrit Change Ie373d1f407788a8e2456c3d8a34cc79ac9ed8bb6),ACTION ON ISSUE 254073,load.php error? many symptoms...,Related URL: https://gerrit.wikimedia.org/r/70805 (Gerrit Change I02ed22e324435e362cabdfc67e69c224ad9e2550),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I02ed22e324435e362cabdfc67e69c224ad9e2550),TASK PROGRESS 254067,load.php error? many symptoms...,"In the exception.log I also got a bunch of: 2013-06-26 22:39:51 deployment-jobrunner08 aawiki: [ff75b05a] [no req] Exception from line 32 of /data/project/apache/common-local/php-master/extensions/MwEmbedSupport/MwEmbedResourceManager.php: MwEmbedResourceManager::register not given readable path: extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer It seems the issue is caused by https://gerrit.wikimedia.org/r/#/c/69479/ ""Register resources with absolute path"" which is intended to fix bug 45918 ""MwEmbedSupport doesn't work with non standard layouts""",task_subcomment,"In the exception.log I also got a bunch of: 2013-06-26 22:39:51 deployment-jobrunner08 aawiki: [ff75b05a] [no req] Exception from line 32 of /data/project/apache/common-local/php-master/extensions/MwEmbedSupport/MwEmbedResourceManager.php: MwEmbedResourceManager::register not given readable path: extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer It seems the issue is caused by URL ""Register resources with absolute path"" which is intended to fix bug 45918 ""MwEmbedSupport doesn't work with non standard layouts""",BUG REPRODUCTION 254061,load.php error? many symptoms...,"exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: ""/usr/local/apache/common-local/php-master/er/extensions/MwEmbedSupport/MwEmbedModules/MediaWikiSupport/MediaWikiSupport.loader.js""' in /data/project/apache/common-local/php-master/includes/resourceloader/ResourceLoaderFileModule.php:574",task_subcomment,"exception 'MWException' with message 'ResourceLoaderFileModule::readScriptFiles: script file not found: ""/usr/local/apache/common-local/php-master/er/extensions/MwEmbedSupport/MwEmbedModules/MediaWikiSupport/MediaWikiSupport.loader.js""' in /data/project/apache/common-local/php-master/includes/resourceloader/ResourceLoaderFileModule.php:574",BUG REPRODUCTION 254057,load.php error? many symptoms...,"not a blocker, sorry, mw.o is a workaround",task_subcomment,"not a blocker, sorry, mw.o is a workaround",WORKAROUNDS 254054,load.php error? many symptoms...,"This also breaks Wikilove on beta. In about 24 hours I will be giving a training session at WMF for 50 people about browser test automation that I had intended to do with Wikilove on beta labs. While I could move the demo to mw.o instead, that would be less than ideal.",task_subcomment,"This also breaks Wikilove on beta. In about 24 hours I will be giving a training session at WMF for 50 people about browser test automation that I had intended to do with Wikilove on beta labs. While I could move the demo to mw.o instead, that would be less than ideal.",FUTURE PLAN 52259,VisualEditor: Silent clean-up of untouched references and templates,"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",task_description,"I made a grammar fix (one word), and did not check the differences before saving. Mistake! :) URL 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",SOLUTION DISCUSSION 253805,VisualEditor: Silent clean-up of untouched references and templates,"Yeah, this is a quite bad problem to have. Thankfully, we believe that the majority of these issues have now been fixed (since that edit of yours) - so I'm going to mark this as fixed. There are no-doubt other issues we've yet to spot, but we've fixed this one. :-) Sorry for the inconvenience!",task_subcomment,"Yeah, this is a quite bad problem to have. Thankfully, we believe that the majority of these issues have now been fixed (since that edit of yours) - so I'm going to mark this as fixed. There are no-doubt other issues we've yet to spot, but we've fixed this one. :-) Sorry for the inconvenience!",ACTION ON ISSUE 52246,VisualEditor: Be able to have enabled for all logged-in users but not anonymous users,"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",task_description,"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",SOLUTION DISCUSSION 253157,VisualEditor: Be able to have enabled for all logged-in users but not anonymous users,We achieved this. Obviously. :-),task_subcomment,We achieved this. Obviously. :-),ACTION ON ISSUE 52241,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook","Screenshot See screenshot. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11809}",task_description,"Screenshot See screenshot. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11809}",BUG REPRODUCTION 252937,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook","Change 70851 merged by jenkins-bot: Make local overlays local to surface and remove insane z-indexes https://gerrit.wikimedia.org/r/70851",task_subcomment,"Change 70851 merged by jenkins-bot: Make local overlays local to surface and remove insane z-indexes GERRIT_URL",ACTION ON ISSUE 252931,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook","Change 70851 had a related patch set uploaded by Robmoen: Make local overlays local to surface and remove insane z-indexes https://gerrit.wikimedia.org/r/70851",task_subcomment,"Change 70851 had a related patch set uploaded by Robmoen: Make local overlays local to surface and remove insane z-indexes GERRIT_URL",TASK PROGRESS 252924,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook","Appears to be now fixed; marking as resolved. Thanks, Rob! :)",task_subcomment,"Appears to be now fixed; marking as resolved. Thanks, Rob! :)",SOLUTION USAGE 252916,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook",Rob's working on re-doing our z-indexes and inheritance right now.,task_subcomment,Rob's working on re-doing our z-indexes and inheritance right now.,WORKAROUNDS 252908,"VisualEditor: Dialogs, inspector menu, link inspector etc. appear behind the document in Monobook","(Firefox 21.0, Windows 7)",task_subcomment,"(Firefox 21.0, Windows 7)",BUG REPRODUCTION 52159,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu","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}",task_description,"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}",BUG REPRODUCTION 248247,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu",Fixed and will be going out in a few minutes.,task_subcomment,Fixed and will be going out in a few minutes.,SOLUTION USAGE 248241,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu","Change 70859 merged by jenkins-bot: Local Overlay Stacks https://gerrit.wikimedia.org/r/70859",task_subcomment,"Change 70859 merged by jenkins-bot: Local Overlay Stacks GERRIT_URL",ACTION ON ISSUE 248233,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu","Change 70859 had a related patch set uploaded by Jforrester: Local Overlay Stacks https://gerrit.wikimedia.org/r/70859",task_subcomment,"Change 70859 had a related patch set uploaded by Jforrester: Local Overlay Stacks GERRIT_URL",ACTION ON ISSUE 248226,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu",Also in Safari 6 for me.,task_subcomment,Also in Safari 6 for me.,BUG REPRODUCTION 248219,"VisualEditor: Resize hover phantom has too high a z-index, so users are unable to click on the image inspector menu",I confirm this in Firefox 21 on enwp.,task_subcomment,I confirm this in Firefox 21 on enwp.,BUG REPRODUCTION 52140,VisualEditor: Link inspector creates the text twice if not running on a selection,"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",task_description,"When using the control/command+k shortcut, and manually typing the text of the desired page to be linked, duplicate links are produced. See URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 247267,VisualEditor: Link inspector creates the text twice if not running on a selection,"(In reply to comment #5) > Great! Thanks for the quick response, James and team! Our pleasure; sorry it happened in the first place.",task_subcomment,"(In reply to comment #5) QUOTE Our pleasure; sorry it happened in the first place.",ACTION ON ISSUE 247261,VisualEditor: Link inspector creates the text twice if not running on a selection,"Great! Thanks for the quick response, James and team!",task_subcomment,"Great! Thanks for the quick response, James and team!",SOLUTION USAGE 247255,VisualEditor: Link inspector creates the text twice if not running on a selection,Fixed and being deployed right now.,task_subcomment,Fixed and being deployed right now.,SOLUTION USAGE 247249,VisualEditor: Link inspector creates the text twice if not running on a selection,Related URL: https://gerrit.wikimedia.org/r/70623 (Gerrit Change I8c68468a95cddbc7efb222cf3a1f9868b2949285),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I8c68468a95cddbc7efb222cf3a1f9868b2949285),ACTION ON ISSUE 247242,VisualEditor: Link inspector creates the text twice if not running on a selection,*** Bug 50188 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50188 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 247238,VisualEditor: Link inspector creates the text twice if not running on a selection,Confirmed - happens whenever you use the link inspector on a non-selection (slug or otherwise). Ed?,task_subcomment,Confirmed - happens whenever you use the link inspector on a non-selection (slug or otherwise). Ed?,BUG REPRODUCTION 52129,VisualEditor: Transclusions not properly round-tripped,"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",task_description,"When doing a simple test edit on URL 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**: URL **See Also**: URL",BUG REPRODUCTION 246566,VisualEditor: Transclusions not properly round-tripped,"I don't see the Dub Jones issue any more, so that appears to be fixed. There was also an independent Parsoid issue that resulted in incomplete DSR on transclusions, which is now also fixed. If you don't see this issue any more then this bug can be closed as fixed.",task_subcomment,"I don't see the Dub Jones issue any more, so that appears to be fixed. There was also an independent Parsoid issue that resulted in incomplete DSR on transclusions, which is now also fixed. If you don't see this issue any more then this bug can be closed as fixed.",ISSUE CONTENT MANAGEMENT 246560,VisualEditor: Transclusions not properly round-tripped,"(In reply to comment #7) > Another case: > https://en.wikipedia.org/w/index. > php?title=Dub_Jones_%28American_football%29&curid=5240085&diff=561834911&oldi > d=561833425 WFM when I tried to reproduce at http://en.wikipedia.org/wiki/User:Catrope/Dub_Jones?veaction=edit . VE's sanity check says the DOM is clean. I believe these failures are due to cached content or some sort of bug in Parsoid/selser.",task_subcomment,"(In reply to comment #7) QUOTE QUOTE QUOTE QUOTE WFM when I tried to reproduce at URL . VE's sanity check says the DOM is clean. I believe these failures are due to cached content or some sort of bug in Parsoid/selser.",BUG REPRODUCTION 246552,VisualEditor: Transclusions not properly round-tripped,"Another case: https://en.wikipedia.org/w/index.php?title=Dub_Jones_%28American_football%29&curid=5240085&diff=561834911&oldid=561833425",task_subcomment,"Another case: URL",SOLUTION DISCUSSION 246544,VisualEditor: Transclusions not properly round-tripped,"Another example where an unmodified template was dirtied: https://en.wikipedia.org/w/index.php?title=User%3AEdgepedia%2FVE%2FGNoSR&diff=561782383&oldid=561781680 Since our DOM diff is so simple I have a lot of faith in it. Did you diff the template DOM fragment after making an unrelated change?",task_subcomment,"Another example where an unmodified template was dirtied: URL Since our DOM diff is so simple I have a lot of faith in it. Did you diff the template DOM fragment after making an unrelated change?",SOLUTION DISCUSSION 246537,VisualEditor: Transclusions not properly round-tripped,"(In reply to comment #4) > At least one {{expand section|..}} transclusion still dirty-diffs. > > This will soon not show up as a diff any more because we improved our native > serialization, but it seems that the VE still dirties the transclusion, which > needs to be fixed. It doesn't seem to be dirtied by VE directly. On [[Chloroplast]], I get a clean diff if I don't make any changes, but a dirty diff if I make any change at all. This leads me to suspect a selser / DOMDiffer bug. Will try to produce a minimal test case and investigate from there.",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE QUOTE It doesn't seem to be dirtied by VE directly. On [[Chloroplast]], I get a clean diff if I don't make any changes, but a dirty diff if I make any change at all. This leads me to suspect a selser / DOMDiffer bug. Will try to produce a minimal test case and investigate from there.",INVESTIGATION AND EXPLORATION 246529,VisualEditor: Transclusions not properly round-tripped,"At least one {{expand section|..}} transclusion still dirty-diffs. This will soon not show up as a diff any more because we improved our native serialization, but it seems that the VE still dirties the transclusion, which needs to be fixed.",task_subcomment,"At least one {{expand section|..}} transclusion still dirty-diffs. This will soon not show up as a diff any more because we improved our native serialization, but it seems that the VE still dirties the transclusion, which needs to be fixed.",BUG REPRODUCTION 246522,VisualEditor: Transclusions not properly round-tripped," *** This bug has been marked as a duplicate of bug 50070 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50070 ***",ACTION ON ISSUE 246515,VisualEditor: Transclusions not properly round-tripped,The nowiki escaping in Schuylar_Oordt is Parsoid bug 50144. It would normally be hidden with selective serialization.,task_subcomment,The nowiki escaping in Schuylar_Oordt is Parsoid bug 50144. It would normally be hidden with selective serialization.,BUG REPRODUCTION 246508,VisualEditor: Transclusions not properly round-tripped,"Some more examples from https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges: https://en.wikipedia.org/w/index.php?title=Eugenio_Fojo&curid=33949576&diff=561434486&oldid=561304103 https://en.wikipedia.org/w/index.php?title=Schuylar_Oordt&curid=37614262&diff=561438828&oldid=561406705",task_subcomment,"Some more examples from URL URL URL",SOLUTION DISCUSSION 52120,Categories/default sort sometimes duplicated to random position in DOM after edit,"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",task_description,"URL I added a single letter (""therafter"" --> ""thereafter""). VisualEditor duplicated the categories and the default sort. -------------------------- **Version**: unspecified **Severity**: major **See Also**: URL URL URL",BUG REPRODUCTION 245935,Categories/default sort sometimes duplicated to random position in DOM after edit,"The Parsoid fix is deployed. The P-wrapping portion is verified fixed on our test case [[Tim_Gartrell]]. The VE newline migration should be tracked in a different bug. Closing this bug as fixed.",task_subcomment,"The Parsoid fix is deployed. The P-wrapping portion is verified fixed on our test case [[Tim_Gartrell]]. The VE newline migration should be tracked in a different bug. Closing this bug as fixed.",TASK PROGRESS 245932,Categories/default sort sometimes duplicated to random position in DOM after edit,"Change 73113 merged by jenkins-bot: Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks https://gerrit.wikimedia.org/r/73113",task_subcomment,"Change 73113 merged by jenkins-bot: Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks GERRIT_URL",ACTION ON ISSUE 245929,Categories/default sort sometimes duplicated to random position in DOM after edit,"Change 73113 had a related patch set uploaded by GWicke: Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks https://gerrit.wikimedia.org/r/73113",task_subcomment,"Change 73113 had a related patch set uploaded by GWicke: Bug 50120: Avoid paragraph wrapping for DOM fragments with blocks GERRIT_URL",SOLUTION USAGE 245926,Categories/default sort sometimes duplicated to random position in DOM after edit,"Subbu, Gabriel and I figured this out on IRC, and Subbu and Gabriel are working on a fix. Summary for the benefit of those following this bug: * On the first parse (either upon first VE load after the cache is purged, or upon the first edit after the purge), Parsoid parses the PERSONDATA template from scratch (because there is no cached content to reuse) and does so correctly. The output is something like \n...
* On the second parse, (first or second edit after cache purge), Parsoid reuses the template expansion from the first parse. It notices that the first (span) and last (link) nodes are both inline, and so it assumes the entire template is inline and wraps it in a

* The browser receives this HTML and is unhappy about the inside the

, so it moves both the

and the out of the

, leaving

\n

...
. Because the table is not a sibling of the span, VE doesn't recognize the table (or the link) as part of the template. Due to a separate bug in VE, the newline after the link is moved and ends up between the table and the link. * VE sends this corrupted HTML back to Parsoid, which freaks out and duplicates the table as well as a bunch of categories. * After the page is edited again (possibly by the user saving the corrupted VE output, possibly some other way), the third parse occurs, and Parsoid again tries to reuse the previous parse's expansion of the template. However, because of the

interruption, it only sees the span and doesn't see the table or the link. The table and the link disappear from the output in this and all subsequent parses, masking the bug. The user doesn't notice because the table has style=""display:none;""",task_subcomment,"Subbu, Gabriel and I figured this out on IRC, and Subbu and Gabriel are working on a fix. Summary for the benefit of those following this bug: * On the first parse (either upon first VE load after the cache is purged, or upon the first edit after the purge), Parsoid parses the PERSONDATA template from scratch (because there is no cached content to reuse) and does so correctly. The output is something like \n...
* On the second parse, (first or second edit after cache purge), Parsoid reuses the template expansion from the first parse. It notices that the first (span) and last (link) nodes are both inline, and so it assumes the entire template is inline and wraps it in a

* The browser receives this HTML and is unhappy about the inside the

, so it moves both the

and the out of the

, leaving

\n

...
. Because the table is not a sibling of the span, VE doesn't recognize the table (or the link) as part of the template. Due to a separate bug in VE, the newline after the link is moved and ends up between the table and the link. * VE sends this corrupted HTML back to Parsoid, which freaks out and duplicates the table as well as a bunch of categories. * After the page is edited again (possibly by the user saving the corrupted VE output, possibly some other way), the third parse occurs, and Parsoid again tries to reuse the previous parse's expansion of the template. However, because of the

interruption, it only sees the span and doesn't see the table or the link. The table and the link disappear from the output in this and all subsequent parses, masking the bug. The user doesn't notice because the table has style=""display:none;""",BUG REPRODUCTION 245920,Categories/default sort sometimes duplicated to random position in DOM after edit,https://en.wikipedia.org/w/index.php?title=Tim_Gartrell&curid=1659124&diff=563696826&oldid=563696785,task_subcomment,URL,ACTION ON ISSUE 245911,Categories/default sort sometimes duplicated to random position in DOM after edit,*** Bug 50554 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50554 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 245904,Categories/default sort sometimes duplicated to random position in DOM after edit,"See also: bug 50554, bug 50385.",task_subcomment,"See also: bug 50554, bug 50385.",SOLUTION USAGE 245897,Categories/default sort sometimes duplicated to random position in DOM after edit,"Another case: https://en.wikipedia.org/w/index.php?title=Frederick_Calvert,_6th_Baron_Baltimore&curid=884173&diff=563705563&oldid=563705411 Also updated the subject and moved to VE.",task_subcomment,"Another case: URL Also updated the subject and moved to VE.",SOLUTION DISCUSSION 245890,Categories/default sort sometimes duplicated to random position in DOM after edit,"That's really strange. The template is one unit in the VE data model, so if tags are placed in the middle of it that must be a bug in the data model -> HTML conversion, not in the data model itself.",task_subcomment,"That's really strange. The template is one unit in the VE data model, so if tags are placed in the middle of it that must be a bug in the data model -> HTML conversion, not in the data model itself.",BUG REPRODUCTION 245884,Categories/default sort sometimes duplicated to random position in DOM after edit,"(In reply to comment #15) > So, there may also be a Parsoid issue here about how such templates are > parsed. As long as the content (including ws-only spans) is properly encapsulated that should not be relevant for this corruption. I have seen VE move categories to random places in the DOM before. Apparently that bug is still alive. And hard to reproduce, sadly.",task_subcomment,"(In reply to comment #15) QUOTE QUOTE As long as the content (including ws-only spans) is properly encapsulated that should not be relevant for this corruption. I have seen VE move categories to random places in the DOM before. Apparently that bug is still alive. And hard to reproduce, sadly.",MOTIVATION 245878,Categories/default sort sometimes duplicated to random position in DOM after edit,Possibly related: bug 50332.,task_subcomment,Possibly related: bug 50332.,POTENTIAL NEW ISSUES AND REQUESTS 245873,Categories/default sort sometimes duplicated to random position in DOM after edit,"And, I misspoke. The spans from the template before/after the table are not really ""empty"" -- they have whitespace. And, the more interesting thing is that these spans do not get the display:none; css style but the table gets it from the style on the table ==> the spans are technically visible (with whitespace ignored in the browser) in VE, but the table is not. So, there may also be a Parsoid issue here about how such templates are parsed.",task_subcomment,"And, I misspoke. The spans from the template before/after the table are not really ""empty"" -- they have whitespace. And, the more interesting thing is that these spans do not get the display:none; css style but the table gets it from the style on the table ==> the spans are technically visible (with whitespace ignored in the browser) in VE, but the table is not. So, there may also be a Parsoid issue here about how such templates are parsed.",BUG REPRODUCTION 245868,Categories/default sort sometimes duplicated to random position in DOM after edit,"This may be a VE bug (unconfirmed). Here is what I did. I parsed mw:Jayaprakash Narayan on my local parsoid install and saved the HTML. I then added a (a new category essentially mimicking editor behavior), but I added it between the empty span that marks the opening of the Persondata tmeplate and the that is part of the template. This effectively splits the template and duplicates the rest of the template. If you look at the diff in https://en.wikipedia.org/w/index.php?title=Jayaprakash_Narayan&diff=563627722&oldid=563627392, all the categories are between the end of the template and the table. The above experiment yielded something similar, except in the diff, all categories are moved up. So, it does seem that when a user adds categories, new/old categories are being moved/inserted between the empty span and the table breaking the atomic encapsulated template into two. Also note that this only seems to affect Persondata template * in original wikitext, default sort template immediately follows the persondata template. * it has an empty span before/after the table * it has display:none set on it which means it doesn't show up in the editor. Not sure if cursor position affects where categories are inserted. Can VE folks verify this hypothesis?",task_subcomment,"This may be a VE bug (unconfirmed). Here is what I did. I parsed mw:Jayaprakash Narayan on my local parsoid install and saved the HTML. I then added a (a new category essentially mimicking editor behavior), but I added it between the empty span that marks the opening of the Persondata tmeplate and the
that is part of the template. This effectively splits the template and duplicates the rest of the template. If you look at the diff in URL all the categories are between the end of the template and the table. The above experiment yielded something similar, except in the diff, all categories are moved up. So, it does seem that when a user adds categories, new/old categories are being moved/inserted between the empty span and the table breaking the atomic encapsulated template into two. Also note that this only seems to affect Persondata template * in original wikitext, default sort template immediately follows the persondata template. * it has an empty span before/after the table * it has display:none set on it which means it doesn't show up in the editor. Not sure if cursor position affects where categories are inserted. Can VE folks verify this hypothesis?",INVESTIGATION AND EXPLORATION 245862,Categories/default sort sometimes duplicated to random position in DOM after edit,"Couple more: https://en.wikipedia.org/w/index.php?title=Peter_Biddle&diff=563624872&oldid=563623995 https://en.wikipedia.org/w/index.php?title=Jayaprakash_Narayan&diff=563627722&oldid=563627392 Based on inspection of recent diffs, I'd call this the single most prevalent and most problematic content corruption issue at this point.",task_subcomment,"Couple more: URL URL Based on inspection of recent diffs, I'd call this the single most prevalent and most problematic content corruption issue at this point.",BUG REPRODUCTION 245856,Categories/default sort sometimes duplicated to random position in DOM after edit,Note the additional table screw-up in that one. We may need some cross-browser hammering on those revs to see if it's a browser-specific issue.,task_subcomment,Note the additional table screw-up in that one. We may need some cross-browser hammering on those revs to see if it's a browser-specific issue.,BUG REPRODUCTION 245852,Categories/default sort sometimes duplicated to random position in DOM after edit,"Another one: https://en.wikipedia.org/w/index.php?title=Rick_DePiro&curid=29139774&diff=563628155&oldid=560712931",task_subcomment,"Another one: URL",ACTION ON ISSUE 245847,Categories/default sort sometimes duplicated to random position in DOM after edit,"Nope, still occurring. https://en.wikipedia.org/w/index.php?title=Ma_Huateng&curid=6152047&diff=563628488&oldid=555028382",task_subcomment,"Nope, still occurring. URL",BUG REPRODUCTION 245840,Categories/default sort sometimes duplicated to random position in DOM after edit,"https://en.wikipedia.org/w/index.php?title=Mat_Devine&curid=28997812&diff=563130933&oldid=563130533 looks like a VE bug to me. I can't reproduce it any more (similar to the case in bug 50853), so I am guessing that something in last night's VE deploy fixed this. Closing as fixed, please reopen if this still happens.",task_subcomment,"URL looks like a VE bug to me. I can't reproduce it any more (similar to the case in bug 50853), so I am guessing that something in last night's VE deploy fixed this. Closing as fixed, please reopen if this still happens.",ACTION ON ISSUE 245836,Categories/default sort sometimes duplicated to random position in DOM after edit,This may be related to bug 50853 which gabriel is going to be investigating to day.,task_subcomment,This may be related to bug 50853 which gabriel is going to be investigating to day.,ACTION ON ISSUE 245830,Categories/default sort sometimes duplicated to random position in DOM after edit,"Is this a Parsoid DSR issue? Content getting repeated in this way (especially, the substituted template) is hard to see occurring in VisualEditor.",task_subcomment,"Is this a Parsoid DSR issue? Content getting repeated in this way (especially, the substituted template) is hard to see occurring in VisualEditor.",BUG REPRODUCTION 245826,Categories/default sort sometimes duplicated to random position in DOM after edit,"This is still occurring. Most recent example from a few minutes ago: https://en.wikipedia.org/w/index.php?title=Mat_Devine&curid=28997812&diff=563130933&oldid=563130533",task_subcomment,"This is still occurring. Most recent example from a few minutes ago: URL",BUG REPRODUCTION 245819,Categories/default sort sometimes duplicated to random position in DOM after edit,We believe that this is now fixed (due to fixes in Parsoid). Please re-open if it recurs.,task_subcomment,We believe that this is now fixed (due to fixes in Parsoid). Please re-open if it recurs.,ACTION ON ISSUE 245813,Categories/default sort sometimes duplicated to random position in DOM after edit,https://en.wikipedia.org/w/index.php?title=Miloslav_Ransdorf&curid=1478506&diff=561858255&oldid=561857291 to boot.,task_subcomment,URL to boot.,URL TO BOOT 245807,Categories/default sort sometimes duplicated to random position in DOM after edit,"Roan, thoughts?",task_subcomment,"Roan, thoughts?",SOLUTION DISCUSSION 245802,Categories/default sort sometimes duplicated to random position in DOM after edit,https://en.wikipedia.org/w/index.php?title=Richard_Ned_Lebow&diff=561410319&oldid=561410032,task_subcomment,URL,ACTION ON ISSUE 245796,Categories/default sort sometimes duplicated to random position in DOM after edit,"Perhaps related to: | PLACE OF BIRTH =[Alexandria], [[Egypt]]",task_subcomment,"Perhaps related to: | PLACE OF BIRTH =[Alexandria], [[Egypt]]",SOLUTION DISCUSSION 52115,VisualEditor: Link editor does not work in the reference editor in Firefox,"Self-explanatory; Firefox 21.0, Windows 7. -------------------------- **Version**: unspecified **Severity**: major",task_description,"Self-explanatory; Firefox 21.0, Windows 7. -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 245554,VisualEditor: Link editor does not work in the reference editor in Firefox,Fixed and will be going out in a few minutes.,task_subcomment,Fixed and will be going out in a few minutes.,SOLUTION USAGE 245548,VisualEditor: Link editor does not work in the reference editor in Firefox,Patched in: https://gerrit.wikimedia.org/r/#/c/70559/,task_subcomment,Patched in: URL,SOLUTION USAGE 52110,VisualEditor: Provide way for local wikis to auto-prompt reference templates,"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",task_description,"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**: URL",FUTURE PLAN 245203,VisualEditor: Provide way for local wikis to auto-prompt reference templates,"Change 119913 merged by jenkins-bot: Ultra-mega-hyper-citation editing on crack https://gerrit.wikimedia.org/r/119913",task_subcomment,"Change 119913 merged by jenkins-bot: Ultra-mega-hyper-citation editing on crack GERRIT_URL",ACTION ON ISSUE 245199,VisualEditor: Provide way for local wikis to auto-prompt reference templates,"Change 119913 had a related patch set uploaded by Jforrester: Ultra-mega-hyper-citation editing on crack https://gerrit.wikimedia.org/r/119913",task_subcomment,"Change 119913 had a related patch set uploaded by Jforrester: Ultra-mega-hyper-citation editing on crack GERRIT_URL",TASK PROGRESS 245195,VisualEditor: Provide way for local wikis to auto-prompt reference templates,*** Bug 51185 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51185 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 245189,VisualEditor: Provide way for local wikis to auto-prompt reference templates,"(In reply to comment #2) > For clarification: I'll assume that this is about what you put _inside_ the > tags and not about templates that add the tags themselves. Correct.",task_subcomment,"(In reply to comment #2) QUOTE QUOTE Correct.",ACTION ON ISSUE 245183,VisualEditor: Provide way for local wikis to auto-prompt reference templates,For clarification: I'll assume that this is about what you put _inside_ the tags and not about templates that add the tags themselves.,task_subcomment,For clarification: I'll assume that this is about what you put _inside_ the tags and not about templates that add the tags themselves.,SOLUTION DISCUSSION 245176,VisualEditor: Provide way for local wikis to auto-prompt reference templates,*** Bug 51683 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51683 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 52073,VisualEditor: Template-based references never editable from reference editor in Firefox,"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}",task_description,"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**: URL **Attached**: {F11445}",BUG REPRODUCTION 242932,VisualEditor: Template-based references never editable from reference editor in Firefox,Related URL: https://gerrit.wikimedia.org/r/70119 (Gerrit Change I29e210aba9a6265d8364ff8ae49408cb4c2428b9),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I29e210aba9a6265d8364ff8ae49408cb4c2428b9),TASK PROGRESS 242925,VisualEditor: Template-based references never editable from reference editor in Firefox,Confirmed by a second user.,task_subcomment,Confirmed by a second user.,BUG REPRODUCTION 52067,"VisualEditor: If a sanity check doesn't work out, encourage the user to do a wikitext diff before saving"," -------------------------- **Version**: unspecified **Severity**: normal",task_description," -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 242549,"VisualEditor: If a sanity check doesn't work out, encourage the user to do a wikitext diff before saving",Written and about to be deployed.,task_subcomment,Written and about to be deployed.,SOLUTION USAGE 242544,"VisualEditor: If a sanity check doesn't work out, encourage the user to do a wikitext diff before saving","Change 70106 merged by jenkins-bot: mw.ViewPageTarget: Add sanity check for DOM roundtrip https://gerrit.wikimedia.org/r/70106",task_subcomment,"Change 70106 merged by jenkins-bot: mw.ViewPageTarget: Add sanity check for DOM roundtrip GERRIT_URL",SOLUTION USAGE 242541,"VisualEditor: If a sanity check doesn't work out, encourage the user to do a wikitext diff before saving",Related URL: https://gerrit.wikimedia.org/r/70106 (Gerrit Change I04f71fe8e00c6257fbc953cc9de3323e24709b0f),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I04f71fe8e00c6257fbc953cc9de3323e24709b0f),TASK PROGRESS 52059,VisualEditor: Metadata not preserved in references,"They get stripped out when rendered back to HTML. e.g. Foo -> Foo -------------------------- **Version**: unspecified **Severity**: normal",task_description,"They get stripped out when rendered back to HTML. e.g. Foo -> Foo -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 242101,VisualEditor: Metadata not preserved in references,Related URL: https://gerrit.wikimedia.org/r/70060 (Gerrit Change I3bbea49132ef4a720a147ba9b170c39a0c00f711),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I3bbea49132ef4a720a147ba9b170c39a0c00f711),ACTION ON ISSUE 52050,VisualEditor: Inline text style annotations with different attributes should not be merged,"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 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",task_description,"Moved from #48830. Merlijn van Deen 2013-06-23 11:20:36 UTC ---------------------------------------- URL 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 tags. Currently it fails compare custom attributes like ""style"" when attempting to merge equal annotation sequences. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: URL",SOLUTION DISCUSSION 241658,VisualEditor: Inline text style annotations with different attributes should not be merged,"We have a work around for this - gerrit 69852 - now in production in VisualEditor, but the underlying cause is bug 48194. I've manually fixed the changes VE made - sorry about that: https://www.mediawiki.org/w/index.php?title=Git/Conversion/pywikipedia&diff=715751&oldid=715067",task_subcomment,"We have a work around for this - gerrit 69852 - now in production in VisualEditor, but the underlying cause is bug 48194. I've manually fixed the changes VE made - sorry about that: URL",WORKAROUNDS 51993,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","This doesn't work; not quite sure why/how. Should be fixed. -------------------------- **Version**: unspecified **Severity**: major",task_description,"This doesn't work; not quite sure why/how. Should be fixed. -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 238346,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow",Fix merged and will hopefully go out soon.,task_subcomment,Fix merged and will hopefully go out soon.,SOLUTION USAGE 238340,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","Change 72069 merged by jenkins-bot: mw.ViewPageTarget.init: Move edit section to top init https://gerrit.wikimedia.org/r/72069",task_subcomment,"Change 72069 merged by jenkins-bot: mw.ViewPageTarget.init: Move edit section to top init GERRIT_URL",SOLUTION USAGE 238334,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","Change 72069 had a related patch set uploaded by Jforrester: mw.ViewPageTarget.init: Move edit section to top init. https://gerrit.wikimedia.org/r/72069",task_subcomment,"Change 72069 had a related patch set uploaded by Jforrester: mw.ViewPageTarget.init: Move edit section to top init. GERRIT_URL",SOLUTION USAGE 238328,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","Gah, bad breakage related to making VE more lightweight - sorry about that. Gerrit 72069 fixes this, according to my local testing - we'll try to get this out today.",task_subcomment,"Gah, bad breakage related to making VE more lightweight - sorry about that. Gerrit 72069 fixes this, according to my local testing - we'll try to get this out today.",SOLUTION DISCUSSION 238322,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","My testing shows that ctrl+click works only in VE-enabled namespaces but middle click works everywhere in Firefox 22. In Konqueror 4.8.5 (which is apparently not enabled for VE) both ctrl+click and middle click both work only in VE-enabled namespaces.",task_subcomment,"My testing shows that ctrl+click works only in VE-enabled namespaces but middle click works everywhere in Firefox 22. In Konqueror 4.8.5 (which is apparently not enabled for VE) both ctrl+click and middle click both work only in VE-enabled namespaces.",BUG REPRODUCTION 238317,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","I'm not sure how the fix was implemented, but it seems to have started occurring again - this time only in namespaces in which the VE isn't active.",task_subcomment,"I'm not sure how the fix was implemented, but it seems to have started occurring again - this time only in namespaces in which the VE isn't active.",BUG REPRODUCTION 238312,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow",Related URL: https://gerrit.wikimedia.org/r/70773 (Gerrit Change I5245ab19ae16b79d2c562c05b94649a58e04a4fd),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I5245ab19ae16b79d2c562c05b94649a58e04a4fd),ACTION ON ISSUE 238307,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow",Fixed in gerrit 70735 which is now merged and will get pushed later today.,task_subcomment,Fixed in gerrit 70735 which is now merged and will get pushed later today.,SOLUTION USAGE 238303,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","Raising importance, this is quite annoying. It's just been reported on [[WP:VPT]] for the second time today.",task_subcomment,"Raising importance, this is quite annoying. It's just been reported on [[WP:VPT]] for the second time today.",ACTION ON ISSUE 238298,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow",*** Bug 50221 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50221 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 238291,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow","**pinkampersand.wikimedia** wrote: I should note that I've been having this bug (well, with ctrl-click on my laptop, but think that's the same thing), and I don't have VE enabled. However, this bug's several days old, and I'm pretty sure this has only been happening to me within the past hour. Chrome on a ChromeOS netbook.",task_subcomment,"**pinkampersand.wikimedia** wrote: I should note that I've been having this bug (well, with ctrl-click on my laptop, but think that's the same thing), and I don't have VE enabled. However, this bug's several days old, and I'm pretty sure this has only been happening to me within the past hour. Chrome on a ChromeOS netbook.",BUG REPRODUCTION 238287,"VisualEditor: Opening ""Edit"" tab (and section edit links) with a middle-click / Ctrl-click / Shift-click (new tab/window) disabled somehow",Some back-of-the-envelope work by users indicates that firefox (logged in) and chromium (logged out) on linux have this problem; firefox and IE on Windows (not logged in) do not.,task_subcomment,Some back-of-the-envelope work by users indicates that firefox (logged in) and chromium (logged out) on linux have this problem; firefox and IE on Windows (not logged in) do not.,OBSERVED BUG BEHAVIOR 51985,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","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",task_description,"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**: URL",BUG REPRODUCTION 237949,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","(In reply to comment #5) > Change 70633 merged by jenkins-bot: > Fix comparison of MW internal links > > https://gerrit.wikimedia.org/r/70633 And with that change, this bug is fixed; closing. It will be deployed this afternoon.",task_subcomment,"(In reply to comment #5) QUOTE QUOTE QUOTE QUOTE And with that change, this bug is fixed; closing. It will be deployed this afternoon.",ACTION ON ISSUE 237941,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","Change 70633 merged by jenkins-bot: Fix comparison of MW internal links https://gerrit.wikimedia.org/r/70633",task_subcomment,"Change 70633 merged by jenkins-bot: Fix comparison of MW internal links GERRIT_URL",ACTION ON ISSUE 237935,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin",Related URL: https://gerrit.wikimedia.org/r/70633 (Gerrit Change I5fb5bfc69c344ca4ce4803d7b6116074648a8d7e),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I5fb5bfc69c344ca4ce4803d7b6116074648a8d7e),ACTION ON ISSUE 237929,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","There are two issues here. First off, we should change getComparableObject() for MWInternalLinkAnnotation to normalize the title and possibly tweak other things to the point where links to the same title are comparable, even if they have different capitalizations or space-vs-underscore variants of that title. That will be both more semantically correct and serve as a workaround for this bug. Secondly, because we want to stop merging comparable but different annotations in the converter, we need Parsoid to correctly process at least things like porcupine (adjacent s with the same href) and possibly porcupine as well (adjacent s with different hrefs that normalize to the same title).",task_subcomment,"There are two issues here. First off, we should change getComparableObject() for MWInternalLinkAnnotation to normalize the title and possibly tweak other things to the point where links to the same title are comparable, even if they have different capitalizations or space-vs-underscore variants of that title. That will be both more semantically correct and serve as a workaround for this bug. Secondly, because we want to stop merging comparable but different annotations in the converter, we need Parsoid to correctly process at least things like porcupine (adjacent s with the same href) and possibly porcupine as well (adjacent s with different hrefs that normalize to the same title).",SOLUTION DISCUSSION 237922,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","Similar but different. This case should definitely be fixed in VE, not Parsoid.",task_subcomment,"Similar but different. This case should definitely be fixed in VE, not Parsoid.",SOLUTION DISCUSSION 237916,"VisualEditor: Adjacent link annotations (one of which is from Parsoid, one from VisualEditor) should conjoin","Ed, is this due to the DM stuff around adjacent annotations?",task_subcomment,"Ed, is this due to the DM stuff around adjacent annotations?",SOLUTION DISCUSSION 51846,mediawiki/extensions.git does not update some extensions,"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",task_description,"URL 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",FUTURE PLAN 750449,mediawiki/extensions.git does not update some extensions,"Change 317923 merged by Dzahn: contint: remove python-requests [[https://gerrit.wikimedia.org/r/317923]]",task_subcomment,"Change 317923 merged by Dzahn: contint: remove python-requests [[GERRIT_URL]]",ACTION ON ISSUE 749667,mediawiki/extensions.git does not update some extensions,"Change 317923 had a related patch set uploaded (by Hashar): contint: remove python-requests [[https://gerrit.wikimedia.org/r/317923]] ",task_subcomment,"Change 317923 had a related patch set uploaded (by Hashar): contint: remove python-requests [[GERRIT_URL]] ",ACTION ON ISSUE 730051,mediawiki/extensions.git does not update some extensions,"Change 311161 merged by Dzahn: contint: drop now unused sudo rule [[https://gerrit.wikimedia.org/r/311161]]",task_subcomment,"Change 311161 merged by Dzahn: contint: drop now unused sudo rule [[GERRIT_URL]]",ACTION ON ISSUE 730024,mediawiki/extensions.git does not update some extensions,"Change 311161 had a related patch set uploaded (by Hashar): contint: drop now unused sudo rule [[https://gerrit.wikimedia.org/r/311161]] ",task_subcomment,"Change 311161 had a related patch set uploaded (by Hashar): contint: drop now unused sudo rule [[GERRIT_URL]] ",ACTION ON ISSUE 725520,mediawiki/extensions.git does not update some extensions,"Change 309275 merged by Giuseppe Lavagetto: ci::master: drop mwext-sync leftover [[https://gerrit.wikimedia.org/r/309275]]",task_subcomment,"Change 309275 merged by Giuseppe Lavagetto: ci::master: drop mwext-sync leftover [[GERRIT_URL]]",TASK PROGRESS 725137,mediawiki/extensions.git does not update some extensions,"Change 309272 merged by jenkins-bot: Remove VE script to sync the Gerrit repo [[https://gerrit.wikimedia.org/r/309272]]",task_subcomment,"Change 309272 merged by jenkins-bot: Remove VE script to sync the Gerrit repo [[GERRIT_URL]]",ACTION ON ISSUE 724762,mediawiki/extensions.git does not update some extensions,"This is confirmed to have been fixed when we have upgraded to Gerrit 2.12. The workaround script and Jenkins job have been removed end of July, the recent changes I have sent above are merely for clean up.",task_subcomment,"This is confirmed to have been fixed when we have upgraded to Gerrit 2.12. The workaround script and Jenkins job have been removed end of July, the recent changes I have sent above are merely for clean up.",SOLUTION USAGE 724761,mediawiki/extensions.git does not update some extensions,"Change 309275 had a related patch set uploaded (by Hashar): ci::master: drop mwext-sync leftover [[https://gerrit.wikimedia.org/r/309275]] ",task_subcomment,"Change 309275 had a related patch set uploaded (by Hashar): ci::master: drop mwext-sync leftover [[GERRIT_URL]] ",ACTION ON ISSUE 724760,mediawiki/extensions.git does not update some extensions,"Change 309272 had a related patch set uploaded (by Hashar): Remove VE script to sync the Gerrit repo [[https://gerrit.wikimedia.org/r/309272]] ",task_subcomment,"Change 309272 had a related patch set uploaded (by Hashar): Remove VE script to sync the Gerrit repo [[GERRIT_URL]] ",ACTION ON ISSUE 724758,mediawiki/extensions.git does not update some extensions,"{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVcJQJLzaH8PnNb4D6OE} [2016-09-08T10:03:29Z] Delete Jenkins job https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/ that has been left behind. It is no more needed. T51846 T86659",task_subcomment,"{nav icon=file, name=Mentioned in SAL, href=URL [2016-09-08T10:03:29Z] Delete Jenkins job URL that has been left behind. It is no more needed. T51846 T86659",ACTION ON ISSUE 724755,mediawiki/extensions.git does not update some extensions,"{nav icon=file, name=Mentioned in SAL, href=https://tools.wmflabs.org/sal/log/AVcJP0y9pirJUPGy-5YX} [2016-09-08T10:02:05Z] Delete mwext-VisualEditor-sync-gerrit job, already got removed by ostriches in 139d17c8f1c4bcf2bb761e13a6501e4d85684066 . The issue in Gerrit (T51846) has been fixed. Poke T86659 , one less job on slaves. ",task_subcomment,"{nav icon=file, name=Mentioned in SAL, href=URL [2016-09-08T10:02:05Z] Delete mwext-VisualEditor-sync-gerrit job, already got removed by ostriches in 139d17c8f1c4bcf2bb761e13a6501e4d85684066 . The issue in Gerrit (T51846) has been fixed. Poke T86659 , one less job on slaves. ",ACTION ON ISSUE 676263,mediawiki/extensions.git does not update some extensions,"Fixed in https://gerrit-review.googlesource.com/#/c/69891/ Upgrading to gerrit 2.12 which will happen soon will fix the problem.",task_subcomment,"Fixed in URL Upgrading to gerrit 2.12 which will happen soon will fix the problem.",SOLUTION USAGE 604483,mediawiki/extensions.git does not update some extensions,Upstream bug is https://code.google.com/p/gerrit/issues/detail?id=2393,task_subcomment,Upstream bug is URL,UPSTREAM BUG 603339,mediawiki/extensions.git does not update some extensions,Same issue with `Cards` and `mediawiki/extensions/Cards` at T125182,task_subcomment,Same issue with CODE and CODE at T125182,BUG REPRODUCTION 254342,mediawiki/extensions.git does not update some extensions,"After much madness, this is now fixed. I had to write a bunch of shell slave scripts to let us properly push the VE update change to mediawiki/extensions.git and self merge them. The job is: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/ It managed to merge an update a few minutes ago: https://gerrit.wikimedia.org/r/#/c/109113/ I guess the issue is fixed now. Sorry for the long time it took to get this fixed.",task_subcomment,"After much madness, this is now fixed. I had to write a bunch of shell slave scripts to let us properly push the VE update change to mediawiki/extensions.git and self merge them. The job is: URL It managed to merge an update a few minutes ago: URL I guess the issue is fixed now. Sorry for the long time it took to get this fixed.",TASK PROGRESS 254337,mediawiki/extensions.git does not update some extensions,"Change 108837 merged by jenkins-bot: mwext-VisualEditor-sync-gerrit on master branch only https://gerrit.wikimedia.org/r/108837",task_subcomment,"Change 108837 merged by jenkins-bot: mwext-VisualEditor-sync-gerrit on master branch only GERRIT_URL",ACTION ON ISSUE 254334,mediawiki/extensions.git does not update some extensions,"Change 108837 had a related patch set uploaded by Hashar: mwext-VisualEditor-sync-gerrit on master branch only https://gerrit.wikimedia.org/r/108837",task_subcomment,"Change 108837 had a related patch set uploaded by Hashar: mwext-VisualEditor-sync-gerrit on master branch only GERRIT_URL",TASK PROGRESS 254331,mediawiki/extensions.git does not update some extensions,"Change 108810 merged by jenkins-bot: trigger mwext-VisualEditor-sync-gerrit on postmerge https://gerrit.wikimedia.org/r/108810",task_subcomment,"Change 108810 merged by jenkins-bot: trigger mwext-VisualEditor-sync-gerrit on postmerge GERRIT_URL",ACTION ON ISSUE 254327,mediawiki/extensions.git does not update some extensions,"Change 108810 had a related patch set uploaded by Hashar: trigger mwext-VisualEditor-sync-gerrit on postmerge https://gerrit.wikimedia.org/r/108810",task_subcomment,"Change 108810 had a related patch set uploaded by Hashar: trigger mwext-VisualEditor-sync-gerrit on postmerge GERRIT_URL",TASK PROGRESS 254323,mediawiki/extensions.git does not update some extensions,"The Gerrit replication got fixed last week. The bot was not able to connect because Gerrit cache accounts credential indefinitely (lowered to 7 days by Chad with https://gerrit.wikimedia.org/r/#/c/108715/ ). I did a few tweaks to adjust the shell script and granted jenkins-bot the ability to CR+2 and V+2 on mediawiki/extensions.git . The first change that self merged is https://gerrit.wikimedia.org/r/#/c/108732/ Gotta add triggers in Zuul.",task_subcomment,"The Gerrit replication got fixed last week. The bot was not able to connect because Gerrit cache accounts credential indefinitely (lowered to 7 days by Chad with URL ). I did a few tweaks to adjust the shell script and granted jenkins-bot the ability to CR+2 and V+2 on mediawiki/extensions.git . The first change that self merged is URL Gotta add triggers in Zuul.",SOLUTION USAGE 254319,mediawiki/extensions.git does not update some extensions,"When jenkins-bot push to Gerrit, Gerrit fetch the email address of the user from the LDAP directory and compare it to the Commiter field of each commit being pushed. Gerrit points to LDAP server virt1000 which is no more replicated from virt1. Hence the jenkins-bot record known to virt1000 is still lacking the email field and thus Gerrit thinks jenkins-bot has no email. This is thus blocked until the virt1 -> virt1000 LDAP replication is fixed.",task_subcomment,"When jenkins-bot push to Gerrit, Gerrit fetch the email address of the user from the LDAP directory and compare it to the Commiter field of each commit being pushed. Gerrit points to LDAP server virt1000 which is no more replicated from virt1. Hence the jenkins-bot record known to virt1000 is still lacking the email field and thus Gerrit thinks jenkins-bot has no email. This is thus blocked until the virt1 -> virt1000 LDAP replication is fixed.",BUG REPRODUCTION 254313,mediawiki/extensions.git does not update some extensions,"Still failing :( https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/9/console",task_subcomment,"Still failing :( URL",BUG REPRODUCTION 254306,mediawiki/extensions.git does not update some extensions,I've manually updated the database until LDAP gets back in sync. You *should* be able to push now.,task_subcomment,I've manually updated the database until LDAP gets back in sync. You *should* be able to push now.,ACTION ON ISSUE 254300,mediawiki/extensions.git does not update some extensions,"Gerrit still believe that jenkins-bot user does not have any email address despite the address being shown in virt0 LDAP. The suspect is that the LDAP replication to virt1000 is broken and that is the server Gerrit is using as a primary. Whenever Gerrit learns about jenkins-bot user, the script I wrote should be able to push its change. The last build I triggered ( https://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/8/console ) yields: 7:14:47 remote: ERROR: In commit c414977bcdbcbdf6331d9fe2e627bc0768695966 17:14:47 remote: ERROR: committer email address jenkins-bot@wikimedia.org 17:14:47 remote: ERROR: does not match your user account. 17:14:47 remote: ERROR: 17:14:47 remote: ERROR: You have not registered any email addresses.",task_subcomment,"Gerrit still believe that jenkins-bot user does not have any email address despite the address being shown in virt0 LDAP. The suspect is that the LDAP replication to virt1000 is broken and that is the server Gerrit is using as a primary. Whenever Gerrit learns about jenkins-bot user, the script I wrote should be able to push its change. The last build I triggered ( URL ) yields: 7:14:47 remote: ERROR: In commit c414977bcdbcbdf6331d9fe2e627bc0768695966 17:14:47 remote: ERROR: committer email address jenkins-bot@wikimedia.org 17:14:47 remote: ERROR: does not match your user account. 17:14:47 remote: ERROR: 17:14:47 remote: ERROR: You have not registered any email addresses.",BUG REPRODUCTION 254296,mediawiki/extensions.git does not update some extensions,"I have added a couple Jenkins slave scripts in integration/jenkins.git bin/gerrit-sync-ve.sh bin/gerrit-sync-ve-push.sh That would update the VisualEditor on a local copy of mediawiki/extensions.git Then had to get a jenkins-bot@wikimedia.org email address registered and assigned to the jenkins-bot Gerrit user. The job mwext-VisualEditor-sync-gerrit still needs to be triggered by Zuul on postmerge. That is an easy change though. Will do whenever I am sure the job is working properly.",task_subcomment,"I have added a couple Jenkins slave scripts in integration/jenkins.git bin/gerrit-sync-ve.sh bin/gerrit-sync-ve-push.sh That would update the VisualEditor on a local copy of mediawiki/extensions.git Then had to get a jenkins-bot@wikimedia.org email address registered and assigned to the jenkins-bot Gerrit user. The job mwext-VisualEditor-sync-gerrit still needs to be triggered by Zuul on postmerge. That is an easy change though. Will do whenever I am sure the job is working properly.",SOLUTION DISCUSSION 254291,mediawiki/extensions.git does not update some extensions,"Change 107862 merged by jenkins-bot: mwext-VisualEditor-sync-gerrit https://gerrit.wikimedia.org/r/107862",task_subcomment,"Change 107862 merged by jenkins-bot: mwext-VisualEditor-sync-gerrit GERRIT_URL",ACTION ON ISSUE 254287,mediawiki/extensions.git does not update some extensions,"Change 107862 had a related patch set uploaded by Hashar: mwext-VisualEditor-sync-gerrit https://gerrit.wikimedia.org/r/107862",task_subcomment,"Change 107862 had a related patch set uploaded by Hashar: mwext-VisualEditor-sync-gerrit GERRIT_URL",ACTION ON ISSUE 254283,mediawiki/extensions.git does not update some extensions,"Change 107853 merged by Andrew Bogott: contint: invoke gerrit-sync-ve-push.sh as jenkins https://gerrit.wikimedia.org/r/107853",task_subcomment,"Change 107853 merged by Andrew Bogott: contint: invoke gerrit-sync-ve-push.sh as jenkins GERRIT_URL",ACTION ON ISSUE 254280,mediawiki/extensions.git does not update some extensions,"Change 107853 had a related patch set uploaded by Hashar: contint: invoke gerrit-sync-ve-push.sh as jenkins https://gerrit.wikimedia.org/r/107853",task_subcomment,"Change 107853 had a related patch set uploaded by Hashar: contint: invoke gerrit-sync-ve-push.sh as jenkins GERRIT_URL",ACTION ON ISSUE 254276,mediawiki/extensions.git does not update some extensions,"Change 107841 merged by jenkins-bot: Script to sync VisualEditor in mediawiki/extensions.git https://gerrit.wikimedia.org/r/107841",task_subcomment,"Change 107841 merged by jenkins-bot: Script to sync VisualEditor in mediawiki/extensions.git GERRIT_URL",ACTION ON ISSUE 254271,mediawiki/extensions.git does not update some extensions,"Change 107841 had a related patch set uploaded by Hashar: Script to sync VisualEditor in mediawiki/extensions.git https://gerrit.wikimedia.org/r/107841",task_subcomment,"Change 107841 had a related patch set uploaded by Hashar: Script to sync VisualEditor in mediawiki/extensions.git GERRIT_URL",TASK PROGRESS 254264,mediawiki/extensions.git does not update some extensions,"Change 107575 abandoned by Hashar: beta: pull VisualEditor individually Reason: Per Chad, will use a Jenkins job to update mediawiki/extensions.git https://gerrit.wikimedia.org/r/107575",task_subcomment,"Change 107575 abandoned by Hashar: beta: pull VisualEditor individually Reason: Per Chad, will use a Jenkins job to update mediawiki/extensions.git GERRIT_URL",ACTION ON ISSUE 254259,mediawiki/extensions.git does not update some extensions,"Change 107574 abandoned by Hashar: unregister VisualEditor (replication broken in Gerrit) Reason: Per Chad, will use a Jenkins job to update mediawiki/extensions.git https://gerrit.wikimedia.org/r/107574",task_subcomment,"Change 107574 abandoned by Hashar: unregister VisualEditor (replication broken in Gerrit) Reason: Per Chad, will use a Jenkins job to update mediawiki/extensions.git GERRIT_URL",ACTION ON ISSUE 254254,mediawiki/extensions.git does not update some extensions,"The patches above: 1) unregister VisualEditor from mediawiki/extensions.git since it is broken anyway 2) make the wmf-beta-autoupdater script to use git pull to refresh the repository",task_subcomment,"The patches above: 1) unregister VisualEditor from mediawiki/extensions.git since it is broken anyway 2) make the wmf-beta-autoupdater script to use git pull to refresh the repository",SOLUTION DISCUSSION 254249,mediawiki/extensions.git does not update some extensions,"Change 107575 had a related patch set uploaded by Hashar: beta: pull VisualEditor individually https://gerrit.wikimedia.org/r/107575",task_subcomment,"Change 107575 had a related patch set uploaded by Hashar: beta: pull VisualEditor individually GERRIT_URL",ACTION ON ISSUE 254247,mediawiki/extensions.git does not update some extensions,"Change 107574 had a related patch set uploaded by Hashar: unregister VisualEditor (replication broken in Gerrit) https://gerrit.wikimedia.org/r/107574",task_subcomment,"Change 107574 had a related patch set uploaded by Hashar: unregister VisualEditor (replication broken in Gerrit) GERRIT_URL",TASK PROGRESS 254244,mediawiki/extensions.git does not update some extensions,"(In reply to comment #29) > (In reply to comment #28) > > We need to do this as a post-merge job in Jenkins for updating the meta-repo. > > The Beta config should be able to remain as-is. > > I am not sure we could do a post-merge job since Zuul does not support > triggering a job according to a project wildcard such as > mediawiki/extensions/* > We don't need to for all repos. Just VisualEditor since it's broken. So we'd adjust the VE zuul/jenkins config to update mediawiki/extensions.git after VE merges. > > I thought we could adapt the 6 minutes wmf-beta-autoupdater.py script, make > it > fetch the list of extensions generated at: > https://gerrit.wikimedia.org/mediawiki-extensions.txt then do a git > submodule > add on all of them and then update them all. Ew. I'd rather keep everything else as it is, keep the workaround to one place (the VE zuul/jenkins config) until the upstream fix takes place. No need to change our infrastructure.",task_subcomment,"(In reply to comment #29) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE We don't need to for all repos. Just VisualEditor since it's broken. So we'd adjust the VE zuul/jenkins config to update mediawiki/extensions.git after VE merges. QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Ew. I'd rather keep everything else as it is, keep the workaround to one place (the VE zuul/jenkins config) until the upstream fix takes place. No need to change our infrastructure.",SOLUTION USAGE 254241,mediawiki/extensions.git does not update some extensions,"(In reply to comment #28) > We need to do this as a post-merge job in Jenkins for updating the meta-repo. > The Beta config should be able to remain as-is. I am not sure we could do a post-merge job since Zuul does not support triggering a job according to a project wildcard such as mediawiki/extensions/* I thought we could adapt the 6 minutes wmf-beta-autoupdater.py script, make it fetch the list of extensions generated at: https://gerrit.wikimedia.org/mediawiki-extensions.txt then do a git submodule add on all of them and then update them all.",task_subcomment,"(In reply to comment #28) QUOTE QUOTE I am not sure we could do a post-merge job since Zuul does not support triggering a job according to a project wildcard such as mediawiki/extensions/* I thought we could adapt the 6 minutes wmf-beta-autoupdater.py script, make it fetch the list of extensions generated at: URL then do a git submodule add on all of them and then update them all.",SOLUTION DISCUSSION 254238,mediawiki/extensions.git does not update some extensions,We need to do this as a post-merge job in Jenkins for updating the meta-repo. The Beta config should be able to remain as-is.,task_subcomment,We need to do this as a post-merge job in Jenkins for updating the meta-repo. The Beta config should be able to remain as-is.,TASK PROGRESS 254233,mediawiki/extensions.git does not update some extensions,Assigning to self and moving to CI,task_subcomment,Assigning to self and moving to CI,ACTION ON ISSUE 254227,mediawiki/extensions.git does not update some extensions,"The root cause is that there are two Gerrit projects being named VisualEditor and there is a bug in Gerrit that get it confused about that and break the automatic update of mediawiki/extensions.git To restore automatic update, we would need to register the extensions locally by iterating over `gerrit ls-projects -p mediawiki/extensions/` and then use git `submodule update --init` as we did previously.",task_subcomment,"The root cause is that there are two Gerrit projects being named VisualEditor and there is a bug in Gerrit that get it confused about that and break the automatic update of mediawiki/extensions.git To restore automatic update, we would need to register the extensions locally by iterating over CODE and then use git CODE as we did previously.",BUG REPRODUCTION 254220,mediawiki/extensions.git does not update some extensions,Re-opening rather than having a fork in bug 59758.,task_subcomment,Re-opening rather than having a fork in bug 59758.,TASK PROGRESS 254213,mediawiki/extensions.git does not update some extensions,*** Bug 59758 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 59758 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 254206,mediawiki/extensions.git does not update some extensions,"happened again, see bug 59758",task_subcomment,"happened again, see bug 59758",BUG REPRODUCTION 254198,mediawiki/extensions.git does not update some extensions,"(In reply to comment #21) > Does anybody plan to investigate on this ticket? > Or is this ""working for us"" right now? > > Wondering if this should still be open, and what's the way forward. The problem was that there was more than one git repos on gerrit called ""VisualEditor"" (namely, mediawiki/extensions/VisualEditor.git and VisualEditor.git with its subsidiaries VisualEditor/core.git, VisualEditor/plugins/.git etc.). We created the other repos to move the code out of MW and make VE properly stand-alone and shippable, but thought we have split the code, we hadn't yet moved the core of VE into the new repo). As a quick hack, Chad deleted the extra repos, which seems to have fixed everything, which means the issue is fixed (and has a known cause), but this isn't sustainable in the longer term as we will likely want to actually do the repo split some time soon (though we could work around the restriction on repo names)… Marking as ""FIXED"", but it's more like ""AVOIDED AT SOME COST"".",task_subcomment,"(In reply to comment #21) QUOTE QUOTE QUOTE QUOTE The problem was that there was more than one git repos on gerrit called ""VisualEditor"" (namely, mediawiki/extensions/VisualEditor.git and VisualEditor.git with its subsidiaries VisualEditor/core.git, VisualEditor/plugins/.git etc.). We created the other repos to move the code out of MW and make VE properly stand-alone and shippable, but thought we have split the code, we hadn't yet moved the core of VE into the new repo). As a quick hack, Chad deleted the extra repos, which seems to have fixed everything, which means the issue is fixed (and has a known cause), but this isn't sustainable in the longer term as we will likely want to actually do the repo split some time soon (though we could work around the restriction on repo names)… Marking as ""FIXED"", but it's more like ""AVOIDED AT SOME COST"".",SOLUTION DISCUSSION 254190,mediawiki/extensions.git does not update some extensions,"Does anybody plan to investigate on this ticket? Or is this ""working for us"" right now? Wondering if this should still be open, and what's the way forward.",task_subcomment,"Does anybody plan to investigate on this ticket? Or is this ""working for us"" right now? Wondering if this should still be open, and what's the way forward.",FUTURE PLAN 254185,mediawiki/extensions.git does not update some extensions,VisualEditor is finally working. I hope. I pray.,task_subcomment,VisualEditor is finally working. I hope. I pray.,ACTION ON ISSUE 254180,mediawiki/extensions.git does not update some extensions,I'm beginning to think this thing is totally broken and a waste of time to use.,task_subcomment,I'm beginning to think this thing is totally broken and a waste of time to use.,BUG REPRODUCTION 254175,mediawiki/extensions.git does not update some extensions,"Sorry DataTypes was dirty in my local copy. That caused git to not update the remaining extensions. It chokes currently on: Cloning into 'ValueFormatters'... remote: Counting objects: 4, done remote: Finding sources: 100% (4/4) remote: Getting sizes: 100% (3/3) remote: Total 4 (delta 0), reused 4 (delta 0) Unpacking objects: 100% (4/4), done. Submodule path 'ValueFormatters': checked out 'b466dde64555d82fcefcdd0b1fe838de2e3acada' fatal: Needed a single revision Unable to find current revision in submodule path 'ValueParsers'",task_subcomment,"Sorry DataTypes was dirty in my local copy. That caused git to not update the remaining extensions. It chokes currently on: Cloning into 'ValueFormatters'... remote: Counting objects: 4, done remote: Finding sources: 100% (4/4) remote: Getting sizes: 100% (3/3) remote: Total 4 (delta 0), reused 4 (delta 0) Unpacking objects: 100% (4/4), done. Submodule path 'ValueFormatters': checked out 'b466dde64555d82fcefcdd0b1fe838de2e3acada' fatal: Needed a single revision Unable to find current revision in submodule path 'ValueParsers'",BUG REPRODUCTION 254168,mediawiki/extensions.git does not update some extensions,"It is apparently totally broken right now. The check-sync.sh script reports a lot of extensions has not being up to date :/ ERROR! DataTypes is lagging behind. ERROR! DataValues is lagging behind. ERROR! DidYouKnow is lagging behind. ERROR! Diff is lagging behind. ERROR! DisableAccount is lagging behind. ERROR! Disambiguator is lagging behind. ERROR! DonationInterface is lagging behind. ERROR! Duplicator is lagging behind. ERROR! EImage is lagging behind. ERROR! Echo is lagging behind. ERROR! EducationProgram is lagging behind. ERROR! EventLogging is lagging behind. ERROR! ExtensionDistributor is lagging behind. ERROR! GettingStarted is lagging behind. ERROR! GlobalBlocking is lagging behind. ERROR! GuidedTour is lagging behind. ERROR! Hovergallery is lagging behind. ERROR! InlineCategorizer is lagging behind. ERROR! Insider is lagging behind. ERROR! LiquidThreads is lagging behind. ERROR! Maps is lagging behind. ERROR! MarkAsHelpful is lagging behind. ERROR! Math is lagging behind. ERROR! MobileFrontend is lagging behind. ERROR! MoodBar is lagging behind. ERROR! Mpdf is lagging behind. ERROR! OAuth is lagging behind. ERROR! Parsoid is lagging behind. ERROR! PdfExport is lagging behind. ERROR! PdfHandler is lagging behind. ERROR! PerPageLicense is lagging behind. ERROR! PronunciationRecording is lagging behind. ERROR! RelatedArticles is lagging behind. ERROR! RevisionCommentSupplement is lagging behind. ERROR! SecurePoll is lagging behind. ERROR! SemanticMediaWiki is lagging behind. ERROR! Thanks is lagging behind. ERROR! TimedMediaHandler is lagging behind. ERROR! Translate is lagging behind. ERROR! TwnMainPage is lagging behind. ERROR! UniversalLanguageSelector is lagging behind. ERROR! UploadWizard is lagging behind. ERROR! ValueFormatters is lagging behind. ERROR! ValueParsers is lagging behind. ERROR! ValueValidators is lagging behind. ERROR! ValueView is lagging behind. ERROR! Vector is lagging behind. ERROR! WikiEditor is lagging behind. ERROR! Wikibase is lagging behind. ERROR! WikibaseDataModel is lagging behind. ERROR! WikibaseDatabase is lagging behind. ERROR! WikibaseQuery is lagging behind. ERROR! WikibaseQueryEngine is lagging behind. ERROR! WikimediaMaintenance is lagging behind. ERROR! WikimediaMessages is lagging behind. ERROR! ZeroRatedMobileAccess is lagging behind.",task_subcomment,"It is apparently totally broken right now. The check-sync.sh script reports a lot of extensions has not being up to date :/ ERROR! DataTypes is lagging behind. ERROR! DataValues is lagging behind. ERROR! DidYouKnow is lagging behind. ERROR! Diff is lagging behind. ERROR! DisableAccount is lagging behind. ERROR! Disambiguator is lagging behind. ERROR! DonationInterface is lagging behind. ERROR! Duplicator is lagging behind. ERROR! EImage is lagging behind. ERROR! Echo is lagging behind. ERROR! EducationProgram is lagging behind. ERROR! EventLogging is lagging behind. ERROR! ExtensionDistributor is lagging behind. ERROR! GettingStarted is lagging behind. ERROR! GlobalBlocking is lagging behind. ERROR! GuidedTour is lagging behind. ERROR! Hovergallery is lagging behind. ERROR! InlineCategorizer is lagging behind. ERROR! Insider is lagging behind. ERROR! LiquidThreads is lagging behind. ERROR! Maps is lagging behind. ERROR! MarkAsHelpful is lagging behind. ERROR! Math is lagging behind. ERROR! MobileFrontend is lagging behind. ERROR! MoodBar is lagging behind. ERROR! Mpdf is lagging behind. ERROR! OAuth is lagging behind. ERROR! Parsoid is lagging behind. ERROR! PdfExport is lagging behind. ERROR! PdfHandler is lagging behind. ERROR! PerPageLicense is lagging behind. ERROR! PronunciationRecording is lagging behind. ERROR! RelatedArticles is lagging behind. ERROR! RevisionCommentSupplement is lagging behind. ERROR! SecurePoll is lagging behind. ERROR! SemanticMediaWiki is lagging behind. ERROR! Thanks is lagging behind. ERROR! TimedMediaHandler is lagging behind. ERROR! Translate is lagging behind. ERROR! TwnMainPage is lagging behind. ERROR! UniversalLanguageSelector is lagging behind. ERROR! UploadWizard is lagging behind. ERROR! ValueFormatters is lagging behind. ERROR! ValueParsers is lagging behind. ERROR! ValueValidators is lagging behind. ERROR! ValueView is lagging behind. ERROR! Vector is lagging behind. ERROR! WikiEditor is lagging behind. ERROR! Wikibase is lagging behind. ERROR! WikibaseDataModel is lagging behind. ERROR! WikibaseDatabase is lagging behind. ERROR! WikibaseQuery is lagging behind. ERROR! WikibaseQueryEngine is lagging behind. ERROR! WikimediaMaintenance is lagging behind. ERROR! WikimediaMessages is lagging behind. ERROR! ZeroRatedMobileAccess is lagging behind.",BUG REPRODUCTION 254164,mediawiki/extensions.git does not update some extensions,*** Bug 51635 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51635 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 254157,mediawiki/extensions.git does not update some extensions,*** Bug 48893 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 48893 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 254150,mediawiki/extensions.git does not update some extensions,"Change 73736 merged by Hashar: update VisualEditor to latest master https://gerrit.wikimedia.org/r/73736",task_subcomment,"Change 73736 merged by Hashar: update VisualEditor to latest master GERRIT_URL",ACTION ON ISSUE 254142,mediawiki/extensions.git does not update some extensions,"Change 73736 had a related patch set uploaded by Hashar: update VisualEditor to latest master https://gerrit.wikimedia.org/r/73736",task_subcomment,"Change 73736 had a related patch set uploaded by Hashar: update VisualEditor to latest master GERRIT_URL",ACTION ON ISSUE 254134,mediawiki/extensions.git does not update some extensions,I hate life.,task_subcomment,I hate life.,SOCIAL CONVERSATION 254130,mediawiki/extensions.git does not update some extensions,"Got broken again a couple hours ago: * ac6c10d - (origin/master, origin/HEAD) Merge ""Bind listener to key... |\ | * 31104d5 - Bind listener to keyup to capture arrows & better ma... * | 877463e - (HEAD) Merge ""Add hooks and classes, initially to s... which shows HEAD not pointing to the same commit as origin/HEAD :(",task_subcomment,"Got broken again a couple hours ago: * ac6c10d - (origin/master, origin/HEAD) Merge ""Bind listener to key... |\ | * 31104d5 - Bind listener to keyup to capture arrows & better ma... * | 877463e - (HEAD) Merge ""Add hooks and classes, initially to s... which shows HEAD not pointing to the same commit as origin/HEAD :(",BUG REPRODUCTION 254126,mediawiki/extensions.git does not update some extensions,"Worked around (decreasing priority), but keeping this open as it might bite us again (as bug 49906 is still open).",task_subcomment,"Worked around (decreasing priority), but keeping this open as it might bite us again (as bug 49906 is still open).",WORKAROUNDS 254122,mediawiki/extensions.git does not update some extensions,"I fixed it before. Now I've fixed it once again. This is annoying.",task_subcomment,"I fixed it before. Now I've fixed it once again. This is annoying.",BUG REPRODUCTION 254119,mediawiki/extensions.git does not update some extensions,"Setting Importance etc since today is ""D Day"" for Visual Editor on ENWiki. Would be great to have betalabs running up to date VE on the day we roll out to a large audience :)",task_subcomment,"Setting Importance etc since today is ""D Day"" for Visual Editor on ENWiki. Would be great to have betalabs running up to date VE on the day we roll out to a large audience :)",SOLUTION USAGE 254117,mediawiki/extensions.git does not update some extensions,"VisualEditor is lagged out again: $ cd extensions $ git remote update $ git rebase $ git submodule update --init VisualEditor Submodule path 'VisualEditor': checked out '46c3d48ba7779254581bfad017c0804588a1983d' $ Then looking at HEAD (that is the checked out version above) and origin/master: $ git log --oneline HEAD..origin/master c331c19 Merge ""Minor performance optimization and cleanup in FocusableNode"" daa83d2 Minor performance optimization and cleanup in FocusableNode a08da9f Make node resizing happen inside onAttributeChange f8d7314 Merge ""Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway"" 87667bd Merge ""Make toolbar look correct with non-standard browser font size settings"" b0b832a Make toolbar look correct with non-standard browser font size settings 59e7a7b Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway $ $ git rev-parse origin/master c331c1980ec37a4d6926f138fd1e81879d5db299 $ git rev-parse HEAD 46c3d48ba7779254581bfad017c0804588a1983d $",task_subcomment,"VisualEditor is lagged out again: $ cd extensions $ git remote update $ git rebase $ git submodule update --init VisualEditor Submodule path 'VisualEditor': checked out '46c3d48ba7779254581bfad017c0804588a1983d' $ Then looking at HEAD (that is the checked out version above) and origin/master: $ git log --oneline HEAD..origin/master c331c19 Merge ""Minor performance optimization and cleanup in FocusableNode"" daa83d2 Minor performance optimization and cleanup in FocusableNode a08da9f Make node resizing happen inside onAttributeChange f8d7314 Merge ""Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway"" 87667bd Merge ""Make toolbar look correct with non-standard browser font size settings"" b0b832a Make toolbar look correct with non-standard browser font size settings 59e7a7b Simplify ve.ce.ResizableNode by removing code for 'transition' which is not used anyway $ $ git rev-parse origin/master c331c1980ec37a4d6926f138fd1e81879d5db299 $ git rev-parse HEAD 46c3d48ba7779254581bfad017c0804588a1983d $",BUG REPRODUCTION 254111,mediawiki/extensions.git does not update some extensions,"http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version VisualEditor (Version 0.1.0) (4b74101) 19:00, 20 June 2013 :-)",task_subcomment,"URL VisualEditor (Version 0.1.0) (4b74101) 19:00, 20 June 2013 :-)",ACTION ON ISSUE 254105,mediawiki/extensions.git does not update some extensions,"I have no idea what went wrong :/ Filled bug 49906 to monitor such issues. Thank you Chad!",task_subcomment,"I have no idea what went wrong :/ Filled bug 49906 to monitor such issues. Thank you Chad!",ACTION ON ISSUE 254096,mediawiki/extensions.git does not update some extensions,"Fixed. gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%'; submodule_project_name | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path -----------------------+-----------------------+----------------------------+---------------------------+--------------- VisualEditor | refs/heads/master | mediawiki/extensions | refs/heads/master | VisualEditor (1 row; 2 ms) gerrit> update submodule_subscriptions set submodule_project_name = 'mediawiki/extensions/VisualEditor' where submodule_path = 'VisualEditor'; UPDATE 1; 2 ms gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%'; submodule_project_name | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path ----------------------------------+-----------------------+----------------------------+---------------------------+--------------- mediawiki/extensions/VisualEditor | refs/heads/master | mediawiki/extensions | refs/heads/master | VisualEditor (1 row; 1 ms) Was the extension at one point pointing to the wrong repository? Will file a bug upstream, since I guess this should've updated itself when the submodule changed.",task_subcomment,"Fixed. gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%'; submodule_project_name | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path -----------------------+-----------------------+----------------------------+---------------------------+--------------- VisualEditor | refs/heads/master | mediawiki/extensions | refs/heads/master | VisualEditor (1 row; 2 ms) gerrit> update submodule_subscriptions set submodule_project_name = 'mediawiki/extensions/VisualEditor' where submodule_path = 'VisualEditor'; UPDATE 1; 2 ms gerrit> select * from submodule_subscriptions where submodule_project_name like '%VisualEditor%'; submodule_project_name | submodule_branch_name | super_project_project_name | super_project_branch_name | submodule_path ----------------------------------+-----------------------+----------------------------+---------------------------+--------------- mediawiki/extensions/VisualEditor | refs/heads/master | mediawiki/extensions | refs/heads/master | VisualEditor (1 row; 1 ms) Was the extension at one point pointing to the wrong repository? Will file a bug upstream, since I guess this should've updated itself when the submodule changed.",SOLUTION USAGE 254090,mediawiki/extensions.git does not update some extensions,Actually moving this bug under 'git/gerrit'.,task_subcomment,Actually moving this bug under 'git/gerrit'.,ACTION ON ISSUE 254084,mediawiki/extensions.git does not update some extensions,"On beta, origin/master points to 5add8cc4c0ea5b305525c30d8af5261406e5d355 which mean VisualEditor remote is not being fetched when running 'git pull && git submodule update --init'.",task_subcomment,"On beta, origin/master points to 5add8cc4c0ea5b305525c30d8af5261406e5d355 which mean VisualEditor remote is not being fetched when running 'git pull && git submodule update --init'.",BUG REPRODUCTION 254076,mediawiki/extensions.git does not update some extensions,"The mediawiki/extensions.git is not updating VisualEditor extension: $ git submodule update --init VisualEditor remote: Counting objects: 3887, done remote: Finding sources: 100% (5930/5930) remote: Getting sizes: 100% (1370/1370) remote: Compressing objects: 21% (288/1370) remote: Total 5930 (delta 3846), reused 5495 (delta 3829) Receiving objects: 100% (5930/5930), 2.95 MiB | 622 KiB/s, done. Resolving deltas: 100% (4091/4091), completed with 275 local objects. From https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor 65602e1..ed1c06e master -> origin/master Submodule path 'VisualEditor': checked out '5add8cc4c0ea5b305525c30d8af5261406e5d355' $ cd VisualEditor $ git rev-parse HEAD origin/master 5add8cc4c0ea5b305525c30d8af5261406e5d355 ed1c06ee6b36851ba1f6e3a68d0584da4c20be46 HEAD should points to the same as origin/master. Parsoid is updated though: $ git rev-parse HEAD origin/master bf8d3dff339e5b3e10f0667850d0114f49db131c bf8d3dff339e5b3e10f0667850d0114f49db131c Moving the bug under Wikimedia > Git/Gerrit . Will poke Chad / Sam about it.",task_subcomment,"The mediawiki/extensions.git is not updating VisualEditor extension: $ git submodule update --init VisualEditor remote: Counting objects: 3887, done remote: Finding sources: 100% (5930/5930) remote: Getting sizes: 100% (1370/1370) remote: Compressing objects: 21% (288/1370) remote: Total 5930 (delta 3846), reused 5495 (delta 3829) Receiving objects: 100% (5930/5930), 2.95 MiB | 622 KiB/s, done. Resolving deltas: 100% (4091/4091), completed with 275 local objects. From URL 65602e1..ed1c06e master -> origin/master Submodule path 'VisualEditor': checked out '5add8cc4c0ea5b305525c30d8af5261406e5d355' $ cd VisualEditor $ git rev-parse HEAD origin/master 5add8cc4c0ea5b305525c30d8af5261406e5d355 ed1c06ee6b36851ba1f6e3a68d0584da4c20be46 HEAD should points to the same as origin/master. Parsoid is updated though: $ git rev-parse HEAD origin/master bf8d3dff339e5b3e10f0667850d0114f49db131c bf8d3dff339e5b3e10f0667850d0114f49db131c Moving the bug under Wikimedia > Git/Gerrit . Will poke Chad / Sam about it.",SOLUTION DISCUSSION 51828,VisualEditor: Parsoid ate a reference,"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",task_description,"In this edit: URL VisualEditor seems to have emptied a reference (the one containing ""Maxime Pargaud"" as author of the cited reference). -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 253136,VisualEditor: Parsoid ate a reference,This is now fixed (Parsoid selser issue); sorry!,task_subcomment,This is now fixed (Parsoid selser issue); sorry!,SOLUTION USAGE 253130,VisualEditor: Parsoid ate a reference,"VisualEditor kissed a girl and liked it. Oh boy, do our products grow up fast. Oh wait, it ate a reference? Bad bad editor. Discipline... Slacker!",task_subcomment,"VisualEditor kissed a girl and liked it. Oh boy, do our products grow up fast. Oh wait, it ate a reference? Bad bad editor. Discipline... Slacker!",SOCIAL CONVERSATION 51763,VisualEditor: Image insertion does not work,"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",task_description,"See URL for the result of four different attempts to insert images. Each one resulted in something like URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 248995,VisualEditor: Image insertion does not work,Fixed. Sorry about this.,task_subcomment,Fixed. Sorry about this.,SOLUTION USAGE 51737,VisualEditor: Page contents replaced 'undefined' (because of an edit conflict?),"https://en.wikipedia.org/w/index.php?title=McIntosh_%28apple%29&diff=560394609&oldid=560264020 -------------------------- **Version**: unspecified **Severity**: normal",task_description,"URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 247487,VisualEditor: Page contents replaced 'undefined' (because of an edit conflict?),"I'm going to speculatively mark this as fixed; we haven't seen any further issues with this and there's no steps to repeat - even when we undertake edit conflicts it still doesn't occur. Please re-open if you find that it does recur - and if so, any information about how to get it to trigger would be great, of course.",task_subcomment,"I'm going to speculatively mark this as fixed; we haven't seen any further issues with this and there's no steps to repeat - even when we undertake edit conflicts it still doesn't occur. Please re-open if you find that it does recur - and if so, any information about how to get it to trigger would be great, of course.",ACTION ON ISSUE 247481,VisualEditor: Page contents replaced 'undefined' (because of an edit conflict?),"(In reply to comment #1) > https://en.wikipedia.org/wiki/Wikipedia: > Village_pump_(technical)#VisualEditor_-_A.2FB_test_launch_on_18_June > > indicates that this might be caused by edit conflicts I can't replicate this, although of course it is difficult to realistically replicate edit conflicts.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE I can't replicate this, although of course it is difficult to realistically replicate edit conflicts.",INVESTIGATION AND EXPLORATION 247472,VisualEditor: Page contents replaced 'undefined' (because of an edit conflict?),"https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#VisualEditor_-_A.2FB_test_launch_on_18_June indicates that this might be caused by edit conflicts",task_subcomment,"URL indicates that this might be caused by edit conflicts",INVESTIGATION AND EXPLORATION 51668,VisualEditor: Page with a block and no s throws fatal error on load,"Have a page with a block but no s and you get: | Uncaught TypeError: Cannot call method 'connect' of null This is bad. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"Have a page with a block but no s and you get: | Uncaught TypeError: Cannot call method 'connect' of null This is bad. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 243087,VisualEditor: Page with a block and no s throws fatal error on load,"This was fixed with gerrit 67924, which is now merged into master and will go out with wmf8 from Thursday.",task_subcomment,"This was fixed with gerrit 67924, which is now merged into master and will go out with wmf8 from Thursday.",SOLUTION USAGE 51608,VisualEditor: HTML comments are dropped from transclusion calls,"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",task_description,"URL 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 URL 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**: URL URL",BUG REPRODUCTION 335980,VisualEditor: HTML comments are dropped from transclusion calls,"verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",task_subcomment,"verified in betalabs and test2 - HTML comments are preserved for both cases - generally and, specifically, in transclusions.",SOLUTION DISCUSSION 335978,VisualEditor: HTML comments are dropped from transclusion calls,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",task_subcomment,"verified in betalabs - HTML comments are preserved both - generally and, specifically, in transclusions.",SOLUTION USAGE 239675,VisualEditor: HTML comments are dropped from transclusion calls,"That's a separate bug, will raise as such.",task_subcomment,"That's a separate bug, will raise as such.",BUG REPRODUCTION 239668,VisualEditor: HTML comments are dropped from transclusion calls,"Not sure if it's the same thing, but I just did this today http://it.wikipedia.org/w/index.php?title=Google&diff=59622535&oldid=59377529 and it discarded commented text which, as noted above, should be there for a reason :)",task_subcomment,"Not sure if it's the same thing, but I just did this today URL and it discarded commented text which, as noted above, should be there for a reason :)",SOLUTION DISCUSSION 239661,VisualEditor: HTML comments are dropped from transclusion calls,"This is now fixed; as an example, see https://en.wikipedia.org/w/index.php?title=Bleak_House&diff=560362551&oldid=560338958 as an edit made with VisualEditor that leaves the comments in the templates as they were.",task_subcomment,"This is now fixed; as an example, see URL as an edit made with VisualEditor that leaves the comments in the templates as they were.",SOLUTION USAGE 239656,VisualEditor: HTML comments are dropped from transclusion calls,Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.,task_subcomment,Can't reproduce in master. The comment appears in the template dialog and can be edited. With experimental code disabled the template is completely untouched.,BUG REPRODUCTION 239650,VisualEditor: HTML comments are dropped from transclusion calls,"(In reply to comment #3) > See also bug 49655 and this (where Ssastry discusses it): > Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",task_subcomment,"(In reply to comment #3) QUOTE QUOTE The place for ""see also"" bugs is the ""see also"" section at the top right of the bug - have put it there. :-) Bug 42124 is not relevant.",ACTION ON ISSUE 239647,VisualEditor: HTML comments are dropped from transclusion calls,"[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",task_subcomment,"[[Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox]] See also bug 42124.",BUG REPRODUCTION 239642,VisualEditor: HTML comments are dropped from transclusion calls,"See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox",task_subcomment,"See also bug 49655 and this (where Ssastry discusses it): Wikipedia:VisualEditor/Feedback#Removal_of_comments_in_Infobox",FUTURE PLAN 239637,VisualEditor: HTML comments are dropped from transclusion calls,"Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in https://www.mediawiki.org/w/index.php?title=VisualEditor:TestComments&diff=712245&oldid=712244 - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",task_subcomment,"Confirm that these are being re-broken, but seemingly online in template calls (where we can't alienate them?). Ed, can you confirm at your end if this is a DM issue or a Parsoid one? I was able to edit around an HTML comment without altering it inline (as expected) in URL - but changes to the HTML comment in the second template fail to be detected as a change (?). Note that the first template can't be edited as the preceding block comment it created as an mw:Placeholder (per bug 47403) and (wrongly?) merged with the following transclusion.",INVESTIGATION AND EXPLORATION 239631,VisualEditor: HTML comments are dropped from transclusion calls,"At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",task_subcomment,"At the time of this discussion by VE developers, [[Wikipedia:VisualEditor/Feedback/Archive 2013 05#General_observations]], hidden notes/comments were preserved. Now all hidden HTML notes on a page (or at least those in templates) are removed when the page is edited by VE. Page edit notices and section edit notices will not work as a replacement since hidden notes can be instructional for specific references, tables, infoboxes, navboxes, sentences, paragraphs, etc.. Page notices and edit notices are for a whole page or section. For more info: [[Wikipedia:VisualEditor/Feedback#HTML_notes]] - or wherever it ends up later in the archives. If HTML notes are going to be replaced by some new hidden notation system, they still need to be preserved in the meantime. They should be treated similarly to how VE handles tables, infoboxes, and other stuff that VE can not currently edit. VE should not be doing anything within templates. Templates are too complex for VE to meddle with in the slightest way. VE should not even remove spaces in templates. If VE ends up with another hidden note tool, then a bot may have to go around to convert all existing hidden HTML notes to the new VE tool. But why bother? Why not keep the HTML notes, and use some kind of popup tooltip in VE that pops up when one puts the mouse cursor over a hidden note icon in VE edit mode? So one can read the hidden note in the popup. Kind of like how reference tooltips work.",SOLUTION DISCUSSION 51596,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"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",task_description,"Adding a file/media fails with wrong wikicode. This wikicode is created, see URL: [[undefined|link=URL -------------------------- **Version**: unspecified **Severity**: major **URL**: URL",BUG REPRODUCTION 238648,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),*** Bug 50021 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50021 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 238642,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"(In reply to comment #10) > What about commend 5 and comment 6? Sorry, yes; created as bug 49849.",task_subcomment,"(In reply to comment #10) QUOTE Sorry, yes; created as bug 49849.",ACTION ON ISSUE 238635,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),What about commend 5 and comment 6?,task_subcomment,What about commend 5 and comment 6?,ACTION ON ISSUE 238628,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"This is partially fixed in gerrit 69581 which we will deploy this afternoon. However, the link issue is still not fixed, thus (in the example in comment 0) we will now 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, but nothing like as terrible as it was. Forking that off to a new bug, bug 49844, and marking this as fixed.",task_subcomment,"This is partially fixed in gerrit 69581 which we will deploy this afternoon. However, the link issue is still not fixed, thus (in the example in comment 0) we will now get: [[File:CV.03326.jpg|link=URL … instead of: [[File:CV.03326.jpg|right|framed|424x275px]] … which is bad, but nothing like as terrible as it was. Forking that off to a new bug, bug 49844, and marking this as fixed.",ACTION ON ISSUE 238619,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"From bug 49829 comment 0: | This is the DOM returned by the VE after inserting a new thumbnail: |
| |
| | Note the 'undefined' in the resource attribute. The resource is the image | target, so we notice that the link and the image named 'undefined' differ and | serialize as | [[undefined|link=http://commons.wikimedia.org/wiki/File:Apples.jpg|thumb]].",task_subcomment,"From bug 49829 comment 0: | This is the DOM returned by the VE after inserting a new thumbnail: |
|
| | Note the 'undefined' in the resource attribute. The resource is the image | target, so we notice that the link and the image named 'undefined' differ and | serialize as | [[undefined|link=URL",BUG REPRODUCTION 238613,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),*** Bug 49829 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 49829 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 238608,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"**winne2i** wrote: The same on plwiki: https://pl.wikipedia.org/w/index.php?diff=36790309 (""prawo"" means ""right"" in polish, ""ramka"" means ""frame"")",task_subcomment,"**winne2i** wrote: The same on plwiki: URL (""prawo"" means ""right"" in polish, ""ramka"" means ""frame"")",BUG REPRODUCTION 238601,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),"(In reply to comment #3) > I get the same type of error: > php?title=PLoS_ONE&diff=36119075&oldid=34872658> On this example there is also something else: I think the code ""direita,right"" should be just ""direita"" or ""right"".",task_subcomment,"(In reply to comment #3) QUOTE QUOTE QUOTE On this example there is also something else: I think the code ""direita,right"" should be just ""direita"" or ""right"".",SOLUTION DISCUSSION 238593,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),*** Bug 49795 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 49795 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 238587,VisualEditor: Adding a file/media fails with wrong wikicode (Image insertion sets resource='undefined'),I get the same type of error: ,task_subcomment,I get the same type of error: All events in Edit_5563071 appear to have the same value for > event_pageViewSessionId (2147483647). It was simply overflowing its column type (int). I set it to 'bigint' and it's fine now. It's odd that we haven't run into this before! It's because we ordinarily convert timestamps to byte strings, like the rest of MediaWiki. This is the first time we've tried to save timestamps as integers. The int type is good for values between +/- 2,147,483,647, which has been adequate for all other use cases. > When fixing, we will want to bump the event_version value. Well, since this did not require a deployment, I instead moved all existing rows in the 'Edit' table to 'z_Edit_5563071'. Any events that go into the current 'Edit_5563071' will be fine.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE It was simply overflowing its column type (int). I set it to 'bigint' and it's fine now. It's odd that we haven't run into this before! It's because we ordinarily convert timestamps to byte strings, like the rest of MediaWiki. This is the first time we've tried to save timestamps as integers. The int type is good for values between +/- 2,147,483,647, which has been adequate for all other use cases. QUOTE Well, since this did not require a deployment, I instead moved all existing rows in the 'Edit' table to 'z_Edit_5563071'. Any events that go into the current 'Edit_5563071' will be fine.",ACTION ON ISSUE 238081,VisualEditor: EventLogging gives the same pageViewSessionId for all edits,"All events in Edit_5563071 appear to have the same value for event_pageViewSessionId (2147483647). When fixing, we will want to bump the event_version value.",task_subcomment,"All events in Edit_5563071 appear to have the same value for event_pageViewSessionId (2147483647). When fixing, we will want to bump the event_version value.",SOLUTION DISCUSSION 51585,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour," -------------------------- **Version**: unspecified **Severity**: normal",task_description," -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 238056,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour,Merged and we'll get this out on Monday so we can test it.,task_subcomment,Merged and we'll get this out on Monday so we can test it.,SOLUTION USAGE 238049,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour,Related URL: https://gerrit.wikimedia.org/r/68712 (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6),task_subcomment,Related URL: GERRIT_URL (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6),TASK PROGRESS 238041,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour,Related URL: https://gerrit.wikimedia.org/r/68712 (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6),task_subcomment,Related URL: GERRIT_URL (Gerrit Change Iddb9eb9c64b55b25445ddf9e474d312b685978a6),TASK PROGRESS 238030,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour,"Coordination card on Trello: https://trello.com/c/xCkMEAY0 Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).",task_subcomment,"Coordination card on Trello: URL Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).",ACTION ON ISSUE 238023,VisualEditor: EventLogging doesn't log user_id so we can't split out user behaviour,"Needs also https://meta.wikimedia.org/wiki/Schema:Edit to be updated first, of course. :-)",task_subcomment,"Needs also URL to be updated first, of course. :-)",SOLUTION USAGE 51577,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"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",task_description,"I have edited the page w:cs:Banolo Blahnik and after saving HTML code was left at the page. See this revision: URL -------------------------- **Version**: unspecified **Severity**: critical",BUG REPRODUCTION 237552,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 50049 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50049 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 237549,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Yes, . It is apparently fixed.",task_subcomment,"Yes, . Should I open a new bug?,task_subcomment,It has the VisualEditor tag and was reported in the feedback page , but that edit was made today.",task_subcomment,Not sure if this is related: Issue started ~ 11:37 UTC today per > https://en.wikipedia.org/w/index. > php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events ... Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events",task_subcomment,"(In reply to comment #3) QUOTE QUOTE QUOTE If that's really accurate *maybe* this has some relevance (posting here in case someone who knows more can do something with it): Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-frontend]/Exec[load-new-vcl-file-frontend]) Triggered 'refresh' from 2 events ... Jun 14 11:34:59 cerium puppet-agent[22506]: (/Stage[main]/Role::Cache::Parsoid/Varnish::Instance[parsoid-backend]/Exec[load-new-vcl-file]) Triggered 'refresh' from 2 events",SOLUTION DISCUSSION 237489,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, http://www.mediawiki.org/w/index.php?title=User%3AHutchy68&diff=711244&oldid=711236",task_subcomment,"Yes, first time I tried the new VisualEditor. My user page is live and I still left the HTML as an example. Tried a few more times to blank page with VE, it is real ugly. HTML leaks on HTML leaks on HTML leaks with each new save, URL",BUG REPRODUCTION 237483,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).,task_subcomment,This is occurring fairly widely and I have a lot of reports. Moving it up to highest priority (because frankly something being broken that is already deployed > anything we might /want/ deployed).,PRIORITY 237474,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,Issue started ~ 11:37 UTC today per https://en.wikipedia.org/w/index.php?namespace=&tagfilter=visualeditor&title=Special%3ARecentChanges,task_subcomment,Issue started ~ 11:37 UTC today per URL,ISSUE CONTENT MANAGEMENT 237461,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,"More of this: https://de.wikipedia.org/w/index.php?title=Oper_K%C3%B6ln&curid=2386780&diff=119548868&oldid=118354900 https://test.wikipedia.org/w/index.php?title=User:Raymond/image&diff=174443&oldid=174442",task_subcomment,"More of this: URL URL",ACTION ON ISSUE 237449,New deployment of Parsoid leads to HTML insertion - needs deployed code reversion,*** Bug 49573 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 49573 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 51403,VisualEditor: En hard-coded as TemplateData fetch language,"Should be user interface language. -------------------------- **Version**: unspecified **Severity**: major",task_description,"Should be user interface language. -------------------------- **Version**: unspecified **Severity**: major",SOLUTION DISCUSSION 251531,VisualEditor: En hard-coded as TemplateData fetch language,"This is resolved in the latest version I3bcf924a3e179cb65f19e833277a39dfd3dad8bd",task_subcomment,"This is resolved in the latest version I3bcf924a3e179cb65f19e833277a39dfd3dad8bd",SOLUTION USAGE 51258,"VisualEditor: Move back to ""normal"" Save dialog with optional rather than mandatory Review","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",task_description,"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",SOLUTION DISCUSSION 242592,"VisualEditor: Move back to ""normal"" Save dialog with optional rather than mandatory Review",Fixed and will go out with wmf7 from next Thursday.,task_subcomment,Fixed and will go out with wmf7 from next Thursday.,SOLUTION USAGE 50769,VisualEditor: Link corruption oddity in production on links (Parsoid issue?)," -------------------------- **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",task_description," -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL **See Also**: URL",SOLUTION USAGE 218104,VisualEditor: Link corruption oddity in production on links (Parsoid issue?),I believe this is now fixed.,task_subcomment,I believe this is now fixed.,SOLUTION USAGE 218095,VisualEditor: Link corruption oddity in production on links (Parsoid issue?),Can't reproduce in master.,task_subcomment,Can't reproduce in master.,BUG REPRODUCTION 50526,VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox,"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",task_description,"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",BUG REPRODUCTION 228977,VisualEditor: Pressing Enter in a heading at the beginning breaks in Firefox,This is not an issue anymore.,task_subcomment,This is not an issue anymore.,ISSUE CONTENT MANAGEMENT 50509,VisualEditor: [Regression] Link inspector button doesn't work,"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",task_description,"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",BUG REPRODUCTION 228003,VisualEditor: [Regression] Link inspector button doesn't work,Merged into master; will go out with wmf5.,task_subcomment,Merged into master; will go out with wmf5.,TASK PROGRESS 227998,VisualEditor: [Regression] Link inspector button doesn't work,Related URL: https://gerrit.wikimedia.org/r/63850 (Gerrit Change Icda3305e422bedaf0d490b8fbe51f55b8c8e79e8),task_subcomment,Related URL: GERRIT_URL (Gerrit Change Icda3305e422bedaf0d490b8fbe51f55b8c8e79e8),ACTION ON ISSUE 227992,VisualEditor: [Regression] Link inspector button doesn't work,"Looks like the format for providing toolbar options was changed, so the MW override isn't working. As a result we're rendering a link button instead of an mwLink. Ctrl+K works because the mwLink is still registered with the command registry (should commands work without the button being rendered?)",task_subcomment,"Looks like the format for providing toolbar options was changed, so the MW override isn't working. As a result we're rendering a link button instead of an mwLink. Ctrl+K works because the mwLink is still registered with the command registry (should commands work without the button being rendered?)",BUG REPRODUCTION 50468,VisualEditor: Pawn appears when creating new list item in Firefox,"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",task_description,"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",BUG REPRODUCTION 225176,VisualEditor: Pawn appears when creating new list item in Firefox,"Solid like a rock! https://www.mediawiki.org/w/index.php?title=User%3AQgil%2FSandbox&diff=710845&oldid=710844 Thank you very much. The bug I filed has been fixed. Resolving accordingly.",task_subcomment,"Solid like a rock! URL Thank you very much. The bug I filed has been fixed. Resolving accordingly.",SOLUTION USAGE 225170,VisualEditor: Pawn appears when creating new list item in Firefox,@Quim: Are you still able to reproduce this problem? I can't.,task_subcomment,SCREEN_NAME: Are you still able to reproduce this problem? I can't.,BUG REPRODUCTION 225163,VisualEditor: Pawn appears when creating new list item in Firefox,"I'm getting similar behaviour on en.wp if you use the slug at the beginning of the article, then change your mind and try to delete the text you've inserted. General behaviour with slug lines?",task_subcomment,"I'm getting similar behaviour on en.wp if you use the slug at the beginning of the article, then change your mind and try to delete the text you've inserted. General behaviour with slug lines?",BUG REPRODUCTION 50390,VisualEditor: Indenting & unindenting multiple list items fails,"Problems in IndentationAction that Ed it working on right now. -------------------------- **Version**: unspecified **Severity**: major",task_description,"Problems in IndentationAction that Ed it working on right now. -------------------------- **Version**: unspecified **Severity**: major",BUG REPRODUCTION 220747,VisualEditor: Indenting & unindenting multiple list items fails,Code is merged into wmf4.,task_subcomment,Code is merged into wmf4.,TASK PROGRESS 220742,VisualEditor: Indenting & unindenting multiple list items fails,Related URL: https://gerrit.wikimedia.org/r/63485 (Gerrit Change I5ce0c385214f30c5e5c66b5b5b755c9937267cd0),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I5ce0c385214f30c5e5c66b5b5b755c9937267cd0),ACTION ON ISSUE 220736,VisualEditor: Indenting & unindenting multiple list items fails,*** Bug 48069 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 48069 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION 220731,VisualEditor: Indenting & unindenting multiple list items fails,"Problem here was with surface fragments and translate range in the data model. The ranges were getting out of sync, so after (un)indenting the first item, and subsequent ones would fail.",task_subcomment,"Problem here was with surface fragments and translate range in the data model. The ranges were getting out of sync, so after (un)indenting the first item, and subsequent ones would fail.",BUG REPRODUCTION 220724,VisualEditor: Indenting & unindenting multiple list items fails,Fixed by https://gerrit.wikimedia.org/r/#/c/63394/,task_subcomment,Fixed by URL,SOLUTION USAGE 50386,VisualEditor: [Regression] Lists badly broken again," -------------------------- **Version**: unspecified **Severity**: critical",task_description," -------------------------- **Version**: unspecified **Severity**: critical",BUG REPRODUCTION 220417,VisualEditor: [Regression] Lists badly broken again,"verified for any page in http://en.wikipedia.beta.wmflabs.org/ using Chrome Version 26.0.1410.65 MAC OS X 10.8.5",task_subcomment,"verified for any page in URL using Chrome Version 26.0.1410.65 MAC OS X 10.8.5",BUG REPRODUCTION 220413,VisualEditor: [Regression] Lists badly broken again,Fixed in https://gerrit.wikimedia.org/r/63413. Will close after it gets merged.,task_subcomment,Fixed in GERRIT_URL. Will close after it gets merged.,SOLUTION USAGE 220410,VisualEditor: [Regression] Lists badly broken again,Related URL: https://gerrit.wikimedia.org/r/63413 (Gerrit Change I8d7aeffc8166487806e3489b054f508c5e9418ff),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I8d7aeffc8166487806e3489b054f508c5e9418ff),TASK PROGRESS 220407,VisualEditor: [Regression] Lists badly broken again,"By stepping back through the commit log I've isolated it down to this commit by Inez: https://gerrit.wikimedia.org/r/#/c/63223/1 Assigning the bug to him.",task_subcomment,"By stepping back through the commit log I've isolated it down to this commit by Inez: URL Assigning the bug to him.",BUG REPRODUCTION 220404,VisualEditor: [Regression] Lists badly broken again,"1. Hitting return inside a list item cases the paragraph to split, not the listitem (that's what shift-return should do) 2. Unlisting the two line list item created in 1. causes the second line to completely disappear 3. Listing two paragraphs only lists the first one, and adds an extra paragraph between them",task_subcomment,"1. Hitting return inside a list item cases the paragraph to split, not the listitem (that's what shift-return should do) 2. Unlisting the two line list item created in 1. causes the second line to completely disappear 3. Listing two paragraphs only lists the first one, and adds an extra paragraph between them",BUG REPRODUCTION 50385,VisualEditor: Delete contents of slugged paragraph results in double line break visible,"* 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
has appeared from nowhere:


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",task_description,"* 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
has appeared from nowhere:


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",BUG REPRODUCTION 220362,VisualEditor: Delete contents of slugged paragraph results in double line break visible,This is fixed with my refactor to handleDelete method.,task_subcomment,This is fixed with my refactor to handleDelete method.,SOLUTION DISCUSSION 220359,VisualEditor: Delete contents of slugged paragraph results in double line break visible,Deeming that this is now fixed.,task_subcomment,Deeming that this is now fixed.,ISSUE CONTENT MANAGEMENT 220355,VisualEditor: Delete contents of slugged paragraph results in double line break visible,"(In reply to comment #1) > We are not placing slugs around lists anymore so this bug can't be > reproduced, however I know what was root cause of it (native handling of > deletion) and I'm working on it now. Is this bug still valid? I can't reproduce now, using a thumb image (rather than a list) to create the block item.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE Is this bug still valid? I can't reproduce now, using a thumb image (rather than a list) to create the block item.",BUG REPRODUCTION 220351,VisualEditor: Delete contents of slugged paragraph results in double line break visible,"We are not placing slugs around lists anymore so this bug can't be reproduced, however I know what was root cause of it (native handling of deletion) and I'm working on it now.",task_subcomment,"We are not placing slugs around lists anymore so this bug can't be reproduced, however I know what was root cause of it (native handling of deletion) and I'm working on it now.",TASK PROGRESS 50346,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","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",task_description,"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. URL -------------------------- **Version**: unspecified **Severity**: critical",BUG REPRODUCTION 218164,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","verified for any page https://test2.wikipedia.org/ using chrome Version 26.0.1410.65 and firefox 25.",task_subcomment,"verified for any page URL using chrome Version 26.0.1410.65 and firefox 25.",BUG REPRODUCTION 218157,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption",Confirming that this is fixed in master and wmf4; deployed in the normal deployment train.,task_subcomment,Confirming that this is fixed in master and wmf4; deployed in the normal deployment train.,SOLUTION USAGE 218151,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","(In reply to comment #4) > Pawn insertion from May 3: > https://en.wikipedia.org/w/index. > php?title=Rubik%27s_360&diff=553360286&oldid=540708795 These kind of issues are precisely why there's a mandatory pre-save diff for users to read and agree it's fine. If there's a pawn inserted into the article, you're not meant to press save!",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE These kind of issues are precisely why there's a mandatory pre-save diff for users to read and agree it's fine. If there's a pawn inserted into the article, you're not meant to press save!",ACTION ON ISSUE 218145,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","(In reply to comment #1) > Steps to reproduce: > 1. Log in and turn on the visual editor. > 2. Go to a random article like ""Sundance Meadows Airport"" > 3. Click the Edit tab > 4. After the cursor appears on the page, type a character > > You will then see a white pawn at the end of the line of text you are > editing. Thanks; have updated the bug report accordingly. > Interestingly, it only seems to happen on articles that insert the cursor > into a blank line at the top of the article. I'm not sure what determines > that behavior, but it seems to be the behavior for the vast majority of > en.wiki articles. That is bug 47790. It's not really a blank line in the document; it's the ""potential"" place to insert some new content, until you click into it and insert some, at which point it's whatever you type in. But it's not really very obvious to users what it is. > The only article I haven't been able to reproduce the bug at so far > is Lalage: > https://en.wikipedia.org/wiki/Lalage A block-level slug only appears if the page starts with a template or other kind of generated content; any page that starts with one will get one (hence the pervasiveness). The alternative is not giving users the ability to insert content before a template if it happened to be at the start of a document, which would be even more confusing.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Thanks; have updated the bug report accordingly. QUOTE QUOTE QUOTE QUOTE That is bug 47790. It's not really a blank line in the document; it's the ""potential"" place to insert some new content, until you click into it and insert some, at which point it's whatever you type in. But it's not really very obvious to users what it is. QUOTE QUOTE QUOTE A block-level slug only appears if the page starts with a template or other kind of generated content; any page that starts with one will get one (hence the pervasiveness). The alternative is not giving users the ability to insert content before a template if it happened to be at the start of a document, which would be even more confusing.",MOTIVATION 218139,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","Can't reproduce this is master. It may have already been fixed, pending release?",task_subcomment,"Can't reproduce this is master. It may have already been fixed, pending release?",BUG REPRODUCTION 218135,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","**fran** wrote: Pawn ahoy: https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/VisualEditor.git;a=blob;f=modules/ve/ce/ve.ce.Surface.js;h=7ad07c54370cb585ca264f78872fee0c83bd77a5;hb=HEAD#l1009 ""git blame"" says this section was worked on by Christian Williams, so maybe he'll know what's going on?",task_subcomment,"**fran** wrote: Pawn ahoy: URL ""git blame"" says this section was worked on by Christian Williams, so maybe he'll know what's going on?",SOLUTION DISCUSSION 218130,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","Pawn insertion from May 3: https://en.wikipedia.org/w/index.php?title=Rubik%27s_360&diff=553360286&oldid=540708795",task_subcomment,"Pawn insertion from May 3: URL",ACTION ON ISSUE 218124,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption",Confirmed in Safari and Chrome as well.,task_subcomment,Confirmed in Safari and Chrome as well.,BUG REPRODUCTION 218117,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","I also can't reproduce the bug in my user sandbox: https://en.wikipedia.org/wiki/User:Kaldari/sandbox",task_subcomment,"I also can't reproduce the bug in my user sandbox: URL",BUG REPRODUCTION 218111,"VisualEditor: Editing a block level slug causes pawns to be inserted, content corruption","Steps to reproduce: 1. Log in and turn on the visual editor. 2. Go to a random article like ""Sundance Meadows Airport"" 3. Click the Edit tab 4. After the cursor appears on the page, type a character You will then see a white pawn at the end of the line of text you are editing. Interestingly, it only seems to happen on articles that insert the cursor into a blank line at the top of the article. I'm not sure what determines that behavior, but it seems to be the behavior for the vast majority of en.wiki articles. The only article I haven't been able to reproduce the bug at so far is Lalage: https://en.wikipedia.org/wiki/Lalage",task_subcomment,"Steps to reproduce: 1. Log in and turn on the visual editor. 2. Go to a random article like ""Sundance Meadows Airport"" 3. Click the Edit tab 4. After the cursor appears on the page, type a character You will then see a white pawn at the end of the line of text you are editing. Interestingly, it only seems to happen on articles that insert the cursor into a blank line at the top of the article. I'm not sure what determines that behavior, but it seems to be the behavior for the vast majority of en.wiki articles. The only article I haven't been able to reproduce the bug at so far is Lalage: URL",BUG REPRODUCTION 50287,VisualEditor: Aborted empty list creates a pawn,"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",task_description,"Go to URL 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",BUG REPRODUCTION 214464,VisualEditor: Aborted empty list creates a pawn,Merged into master; will be deployed from Monday.,task_subcomment,Merged into master; will be deployed from Monday.,TASK PROGRESS 214458,VisualEditor: Aborted empty list creates a pawn,"(In reply to comment #3) > Related URL: https://gerrit.wikimedia.org/r/63102 (Gerrit Change > If22d9b904b8861e24d56944d791545635b2e4254) Merged.",task_subcomment,"(In reply to comment #3) QUOTE QUOTE Merged.",ACTION ON ISSUE 214450,VisualEditor: Aborted empty list creates a pawn,Related URL: https://gerrit.wikimedia.org/r/63102 (Gerrit Change If22d9b904b8861e24d56944d791545635b2e4254),task_subcomment,Related URL: GERRIT_URL (Gerrit Change If22d9b904b8861e24d56944d791545635b2e4254),TASK PROGRESS 214441,VisualEditor: Aborted empty list creates a pawn,"I can reproduce in Firefox and Chrome if you forwards-delete or insert characters. It appears that this is because when you clear out the
  • (return at the end of the list) it doesn't check that the
    • is wrapped in a . Not really WYSIWYG… -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11257}",task_description,"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 is wrapped in a . Not really WYSIWYG… -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11257}",BUG REPRODUCTION 236722,VisualEditor: uneditable table lines displayed wrong,"Yes, merging with bug 50607. *** This bug has been marked as a duplicate of bug 50607 ***",task_subcomment,"Yes, merging with bug 50607. *** This bug has been marked as a duplicate of bug 50607 ***",ACTION ON ISSUE 236716,VisualEditor: uneditable table lines displayed wrong,I think this might be a duplicate of bug 50607,task_subcomment,I think this might be a duplicate of bug 50607,BUG REPRODUCTION 54478,References created by Singlechart cannot be accessed properly,"**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 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",task_description,"**Author:** CODE **Description:** URL is a simple test case for accessing references created by the singlechart template. Singlechart directly creates references when called, using #ref (it cannot use 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 URL 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 URL 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",BUG REPRODUCTION 236424,References created by Singlechart cannot be accessed properly,"Is {{#tag:ref}} something that is part of MediaWiki or something user-generated? If it's part of MediaWiki, presumably its creation and deployment is an indication that it's meant to work.",task_subcomment,"Is {{#tag:ref}} something that is part of MediaWiki or something user-generated? If it's part of MediaWiki, presumably its creation and deployment is an indication that it's meant to work.",SOLUTION DISCUSSION 236417,References created by Singlechart cannot be accessed properly,"**kwwilliams** wrote: That response is beyond the pale. Please retract it, and concentrate on building an editor that functions within the environment that exists, not the environment that you wish existed.",task_subcomment,"**kwwilliams** wrote: That response is beyond the pale. Please retract it, and concentrate on building an editor that functions within the environment that exists, not the environment that you wish existed.",ACTION ON ISSUE 236409,References created by Singlechart cannot be accessed properly,"This is a duplicate of bug 50474 - in general, any reference created by a template shouldn't work, deliberately. Hacks using {{#tag:ref}} which was never meant to work are a nightmare for users and VisualEditor alike. *** This bug has been marked as a duplicate of bug 50474 ***",task_subcomment,"This is a duplicate of bug 50474 - in general, any reference created by a template shouldn't work, deliberately. Hacks using {{#tag:ref}} which was never meant to work are a nightmare for users and VisualEditor alike. *** This bug has been marked as a duplicate of bug 50474 ***",BUG REPRODUCTION 54467,"VisualEditor: if the title page starts with a dot, VE won't load","http://en.wikipedia.org/wiki/.tl for instance, if you click on the Edit tab, nothing will happen. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"URL for instance, if you click on the Edit tab, nothing will happen. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 235784,"VisualEditor: if the title page starts with a dot, VE won't load"," *** This bug has been marked as a duplicate of bug 51308 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 51308 ***",ACTION ON ISSUE 235781,"VisualEditor: if the title page starts with a dot, VE won't load","(I believe I just duplicated https://bugzilla.wikimedia.org/show_bug.cgi?id=51308, sorry about that).",task_subcomment,(I believe I just duplicated URL sorry about that).,ACTION ON ISSUE 54433,VisualEditor: Toolbar not returning under the tabs,"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}",task_description,"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**: URL URL **Attached**: {F11123}",BUG REPRODUCTION 233850,VisualEditor: Toolbar not returning under the tabs,"This is a duplicate of Bug 52441 which is fixed but not yet deployed *** This bug has been marked as a duplicate of bug 52441 ***",task_subcomment,"This is a duplicate of Bug 52441 which is fixed but not yet deployed *** This bug has been marked as a duplicate of bug 52441 ***",BUG REPRODUCTION 54431,VisualEditor: {{clr}} prevents user from editing content,"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 at their end display it, confusing users","(In reply to comment #5) > (In reply to comment #4) > > This is a Parsoid bug. The PHP parser does not generate a for this > > wikitext, and Parsoid does. > > Does the PHP parser create it but it then gets tidied away? That's possible, I haven't checked what happens when Tidy is disabled.",task_subcomment,"(In reply to comment #5) QUOTE QUOTE QUOTE QUOTE QUOTE That's possible, I haven't checked what happens when Tidy is disabled.",SOLUTION DISCUSSION 244534,"VisualEditor: Tables with a faulty at their end display it, confusing users","(In reply to comment #4) > This is a Parsoid bug. The PHP parser does not generate a for this > wikitext, and Parsoid does. Does the PHP parser create it but it then gets tidied away?",task_subcomment,"(In reply to comment #4) QUOTE QUOTE Does the PHP parser create it but it then gets tidied away?",SOLUTION DISCUSSION 244526,"VisualEditor: Tables with a faulty at their end display it, confusing users","This is a Parsoid bug. The PHP parser does not generate a for this wikitext, and Parsoid does.",task_subcomment,"This is a Parsoid bug. The PHP parser does not generate a for this wikitext, and Parsoid does.",BUG REPRODUCTION 244519,"VisualEditor: Tables with a faulty at their end display it, confusing users","(In reply to comment #2) > Makes sense. Alternately would it be possible to add it in as a rule to > Parsoid's voodo wikimarkup-fixing stuff? If a |- is followed by nothing and > then a |}... But some gadgets might rely on that meaning something special for some users. Everything we change or ""fix"" potentially breaks things for some (other) users. :-(",task_subcomment,"(In reply to comment #2) QUOTE QUOTE QUOTE But some gadgets might rely on that meaning something special for some users. Everything we change or ""fix"" potentially breaks things for some (other) users. :-(",SOLUTION DISCUSSION 244513,"VisualEditor: Tables with a faulty at their end display it, confusing users",Makes sense. Alternately would it be possible to add it in as a rule to Parsoid's voodo wikimarkup-fixing stuff? If a |- is followed by nothing and then a |}...,task_subcomment,Makes sense. Alternately would it be possible to add it in as a rule to Parsoid's voodo wikimarkup-fixing stuff? If a |- is followed by nothing and then a |}...,SOLUTION DISCUSSION 244508,"VisualEditor: Tables with a faulty at their end display it, confusing users","This is not a bug (well, it's not a bug with VE :-)) - the three ""broken"" tables all have |- | |- |} … at the end, which is not the case for the third ""working"" one. What you see is the result of broken wikitext. VE is good, but it can't be psychic about what you wanted to do with that that extra table row (maybe you wanted to expand the table and were half-way through?) so behaviour is ""as intended"". Marking as INVALID; in general broken wikitext like this can't be trivially fixed by a bot, due to wikitext's complexities, but it might be worth exploring.",task_subcomment,"This is not a bug (well, it's not a bug with VE :-)) - the three ""broken"" tables all have |- | |- |} … at the end, which is not the case for the third ""working"" one. What you see is the result of broken wikitext. VE is good, but it can't be psychic about what you wanted to do with that that extra table row (maybe you wanted to expand the table and were half-way through?) so behaviour is ""as intended"". Marking as INVALID; in general broken wikitext like this can't be trivially fixed by a bot, due to wikitext's complexities, but it might be worth exploring.",INVESTIGATION AND EXPLORATION 51687,VisualEditor: Template displaying in the incorrect language,"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",task_description,"See the bottom of URL for example - it also occurs at URL and URL (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",BUG REPRODUCTION 244274,VisualEditor: Template displaying in the incorrect language,"This is previously reported (and also they think fixed). *** This bug has been marked as a duplicate of bug 49411 ***",task_subcomment,"This is previously reported (and also they think fixed). *** This bug has been marked as a duplicate of bug 49411 ***",BUG REPRODUCTION 51684,VisualEditor: nowiki tags added to references (and references split up (and content dropped)),"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",task_description,"An example is URL - another is URL where the VisualEditor seems to have taken it upon itself to drop content and convert templates into pure reference tags -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 243906,VisualEditor: nowiki tags added to references (and references split up (and content dropped)),[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE 243902,VisualEditor: nowiki tags added to references (and references split up (and content dropped)),"The {{#tag:ref|…}} issues should now be fixed in production. The specific issues of adding s around wiki-able elements of tables is also, I believe, fixed in production. s around wikitext are, of course, intentional.",task_subcomment,"The {{#tag:ref|…}} issues should now be fixed in production. The specific issues of adding s around wiki-able elements of tables is also, I believe, fixed in production. s around wikitext are, of course, intentional.",SOLUTION USAGE 243898,VisualEditor: nowiki tags added to references (and references split up (and content dropped)),Nowiki tags are also being entered around elements of tables - see https://en.wikipedia.org/w/index.php?title=Guy_McKenna&curid=1748898&diff=560026334&oldid=560026013,task_subcomment,Nowiki tags are also being entered around elements of tables - see URL,BUG REPRODUCTION 51683,VisualEditor: Unexpected padding,"See the tabs on https://en.wikipedia.org/wiki/User:Panpog1 for example. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"See the tabs on URL for example. -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION USAGE 243852,VisualEditor: Unexpected padding,Fixed.,task_subcomment,Fixed.,SOLUTION USAGE 51643,UniversalLanguageSelector Does not work with VisualEditor,"**Author:** `bellayet` **Description:** At bn Wikipedia ULS does not working with recently added VisualEditor beta. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"**Author:** CODE **Description:** At bn Wikipedia ULS does not working with recently added VisualEditor beta. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 241617,UniversalLanguageSelector Does not work with VisualEditor,"True, thanks for reporting. Despite the mysterious bug summary, this is known as bug 49569 :) and is being actively worked on as GSoC project. *** This bug has been marked as a duplicate of bug 49569 ***",task_subcomment,"True, thanks for reporting. Despite the mysterious bug summary, this is known as bug 49569 :) and is being actively worked on as GSoC project. *** This bug has been marked as a duplicate of bug 49569 ***",BUG REPRODUCTION 241610,UniversalLanguageSelector Does not work with VisualEditor,"**bellayet** wrote: ULS Input tool is not supporting VisualEditor.",task_subcomment,"**bellayet** wrote: ULS Input tool is not supporting VisualEditor.",SOLUTION DISCUSSION 51637,VisualEditor bugzilla component should be under MediaWiki extensions,"I failed to find it under extensions where I was expecting it to be. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"I failed to find it under extensions where I was expecting it to be. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 241253,VisualEditor bugzilla component should be under MediaWiki extensions,"(In reply to comment #6) > To be fair the bug summary is rather generic. It would make sense to have a > placeholder under ""MediaWiki extensions"", or maybe a mention of the product > somewhere. The plan is to split the codebase after the beta deployment in a few weeks' time into ""VisualEditor core"" and ""a MediaWiki plug-in that uses this foreign library called VisualEditor"". At that point, it might make sense to re-activate ""MediaWiki extensions > VisualEditor"", if only because that's where people might look for it; I'm happy to triage bugs in two places. In practice you'd likely have most bugs for MW-VE be dependent on VE-core bugs, but that's still manageable. @Andre, thoughts on this?",task_subcomment,"(In reply to comment #6) QUOTE QUOTE QUOTE The plan is to split the codebase after the beta deployment in a few weeks' time into ""VisualEditor core"" and ""a MediaWiki plug-in that uses this foreign library called VisualEditor"". At that point, it might make sense to re-activate ""MediaWiki extensions > VisualEditor"", if only because that's where people might look for it; I'm happy to triage bugs in two places. In practice you'd likely have most bugs for MW-VE be dependent on VE-core bugs, but that's still manageable. SCREEN_NAME, thoughts on this?",SOLUTION DISCUSSION 241243,VisualEditor bugzilla component should be under MediaWiki extensions,"To be fair the bug summary is rather generic. It would make sense to have a placeholder under ""MediaWiki extensions"", or maybe a mention of the product somewhere.",task_subcomment,"To be fair the bug summary is rather generic. It would make sense to have a placeholder under ""MediaWiki extensions"", or maybe a mention of the product somewhere.",SOLUTION DISCUSSION 241237,VisualEditor bugzilla component should be under MediaWiki extensions,"The visual editor backend for MediaWiki, once split out, will actually be a MediaWiki extension, and for that one a component will be created under ""MediaWiki extensions"" in Bugzilla. The VisualEditor product itself will be MW-independent and hence a product on its own. Like now. > I don't see why VisualEditor can't have an entry in MediaWiki extensions. Because the VE product has components in Bugzilla, and Bugzilla does not allow subcomponents (components that are part of a component). If I make the VE product a component under the ""MediaWiki extensions"" product in Bugzilla, VE will have to lose all its components. And we don't want that because it's complex enough to have components.",task_subcomment,"The visual editor backend for MediaWiki, once split out, will actually be a MediaWiki extension, and for that one a component will be created under ""MediaWiki extensions"" in Bugzilla. The VisualEditor product itself will be MW-independent and hence a product on its own. Like now. QUOTE Because the VE product has components in Bugzilla, and Bugzilla does not allow subcomponents (components that are part of a component). If I make the VE product a component under the ""MediaWiki extensions"" product in Bugzilla, VE will have to lose all its components. And we don't want that because it's complex enough to have components.",SOLUTION DISCUSSION 241232,VisualEditor bugzilla component should be under MediaWiki extensions,"I don't see why VisualEditor can't have an entry in MediaWiki extensions. It's a MediaWiki extension. This is a reasonable place to look for it. You can add a note in the description about filing the bugs under a different product, but we certainly don't to lose bugs because people can't figure out where to file them.",task_subcomment,"I don't see why VisualEditor can't have an entry in MediaWiki extensions. It's a MediaWiki extension. This is a reasonable place to look for it. You can add a note in the description about filing the bugs under a different product, but we certainly don't to lose bugs because people can't figure out where to file them.",SOLUTION USAGE 241226,VisualEditor bugzilla component should be under MediaWiki extensions,I doubt many will understand the difference between VE and VE backend (the extension?) .I don't. They shouldn't be called the same.,task_subcomment,I doubt many will understand the difference between VE and VE backend (the extension?) .I don't. They shouldn't be called the same.,SOLUTION DISCUSSION 241220,VisualEditor bugzilla component should be under MediaWiki extensions,...and Bugzilla bugs should be filed under Bugzilla. Moving.,task_subcomment,...and Bugzilla bugs should be filed under Bugzilla. Moving.,ACTION ON ISSUE 241215,VisualEditor bugzilla component should be under MediaWiki extensions,"The VE backend for MediaWiki, once split out, is expected to become an extension on its own (also codewise) soon, but VE itself will stay as a toplevel product. Plus Bugzilla's three levels (classification, product, component) do not allow having subcomponents under components hence not feasible.",task_subcomment,"The VE backend for MediaWiki, once split out, is expected to become an extension on its own (also codewise) soon, but VE itself will stay as a toplevel product. Plus Bugzilla's three levels (classification, product, component) do not allow having subcomponents under components hence not feasible.",FUTURE PLAN 51621,"""Use the wikitext editor for editing sections while VisualEditor is in beta"" should be default","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",task_description,"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**: URL",SOLUTION DISCUSSION 240344,"""Use the wikitext editor for editing sections while VisualEditor is in beta"" should be default",Thanks. I like the chosen solution.,task_subcomment,Thanks. I like the chosen solution.,SOLUTION DISCUSSION 240338,"""Use the wikitext editor for editing sections while VisualEditor is in beta"" should be default","In the end we've gone with a solution to have both links, as requested, so closing this option on the default as INVALID (the option itself doesn't make any sense given the change in the product design).",task_subcomment,"In the end we've gone with a solution to have both links, as requested, so closing this option on the default as INVALID (the option itself doesn't make any sense given the change in the product design).",SOLUTION USAGE 240332,"""Use the wikitext editor for editing sections while VisualEditor is in beta"" should be default","**brassratgirl** wrote: Agreed that having two links would be super. Visual editor for section-editing by default is driving me crazy on the English Wikipedia.",task_subcomment,"**brassratgirl** wrote: Agreed that having two links would be super. Visual editor for section-editing by default is driving me crazy on the English Wikipedia.",SOLUTION USAGE 51587,Implement the same EventLogging of page edits in wikitext editor as in VisualEditor for comparison purposes," -------------------------- **Version**: unspecified **Severity**: normal",task_description," -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 238129,Implement the same EventLogging of page edits in wikitext editor as in VisualEditor for comparison purposes,"This was done by Ori in gerrit 69161 for VisualEditor only; if we want to put this into core, we'll want to do that later, but for now marking this as closed.",task_subcomment,"This was done by Ori in gerrit 69161 for VisualEditor only; if we want to put this into core, we'll want to do that later, but for now marking this as closed.",ACTION ON ISSUE 238124,Implement the same EventLogging of page edits in wikitext editor as in VisualEditor for comparison purposes,"Coordination card on Trello: https://trello.com/c/xCkMEAY0 Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).",task_subcomment,"Coordination card on Trello: URL Reminder: anonymous editors are excluded from logging (we'll instrument the edit funnel for anons in July in preparation for the global launch).",ACTION ON ISSUE 51547,Configure VisualEditor for section edit links to go to VisualEditor by default," -------------------------- **Version**: unspecified **Severity**: normal",task_description," -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 235597,Configure VisualEditor for section edit links to go to VisualEditor by default,Roan implemented this in code rather than as a config of $wgVisualEditorEnableSectionEditLinks; INVLAIDing.,task_subcomment,Roan implemented this in code rather than as a config of $wgVisualEditorEnableSectionEditLinks; INVLAIDing.,SOLUTION DISCUSSION 51545,VisualEditor: Switch over to handle mw:WikiLink/Interwiki,"Currently links with mw:WikiLink/Interwiki get alienated -------------------------- **Version**: unspecified **Severity**: normal",task_description,"Currently links with mw:WikiLink/Interwiki get alienated -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 235513,VisualEditor: Switch over to handle mw:WikiLink/Interwiki,"I'm a fool to myself. *** This bug has been marked as a duplicate of bug 49316 ***",task_subcomment,"I'm a fool to myself. *** This bug has been marked as a duplicate of bug 49316 ***",ACTION ON ISSUE 51540,VisualEditor: valid links are redlinked in the link inspector,"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",task_description,"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",BUG REPRODUCTION 235220,VisualEditor: valid links are redlinked in the link inspector,"Yes, this is specifically that it's filtering out redirects in its suggestions (good) but then assuming that if it's not a non-redirect, it doesn't exist (bad). We'll get this fixed. *** This bug has been marked as a duplicate of bug 49502 ***",task_subcomment,"Yes, this is specifically that it's filtering out redirects in its suggestions (good) but then assuming that if it's not a non-redirect, it doesn't exist (bad). We'll get this fixed. *** This bug has been marked as a duplicate of bug 49502 ***",ACTION ON ISSUE 51525,Extension tags starting with a capital () seem to confuse the parser,"https://en.wikipedia.org/w/index.php?title=User:TheDJ/sandbox&oldid=559712952 Try adding a gallery that was made using Anything following the opening 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",task_description,"URL Try adding a gallery that was made using Anything following the opening tag seems to be enclosed inside it. Also when saving, the following might apparently occur: URL Discussion: URL -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION USAGE 234452,Extension tags starting with a capital () seem to confuse the parser,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE 234447,Extension tags starting with a capital () seem to confuse the parser,https://gerrit.wikimedia.org/r/68727 (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af) | change APPROVED and MERGED [by jenkins-bot],task_subcomment,GERRIT_URL (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af) | change APPROVED and MERGED [by jenkins-bot],ACTION ON ISSUE 234438,Extension tags starting with a capital () seem to confuse the parser,Related URL: https://gerrit.wikimedia.org/r/68727 (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I288f6ec9e4117ce58e2f445e73868937be1654af),TASK PROGRESS 234429,Extension tags starting with a capital () seem to confuse the parser,*** Bug 49579 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 49579 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE 234423,Extension tags starting with a capital () seem to confuse the parser,"Argh, yes, this looks like a Parsoid issue. (I would have thought that all wikitext syntax should be case insensitive?)",task_subcomment,"Argh, yes, this looks like a Parsoid issue. (I would have thought that all wikitext syntax should be case insensitive?)",MOTIVATION 51522,VisualEditor: Mass of extraneous quot and amp marks,"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",task_description,"See URL and URL for example; I have...no idea what's happening. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 234178,VisualEditor: Mass of extraneous quot and amp marks,"I think that we've fixed this bug, but if it recurs please re-open.",task_subcomment,"I think that we've fixed this bug, but if it recurs please re-open.",ACTION ON ISSUE 51486,VisualEditor: Add the ability to drag highlighted text around with the mouse,"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",task_description,"As requested at URL 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",FUTURE PLAN 231896,VisualEditor: Add the ability to drag highlighted text around with the mouse,"bug 41150 was changed to be media objects only; text drag and drop is yet to come. *** This bug has been marked as a duplicate of bug 49981 ***",task_subcomment,"bug 41150 was changed to be media objects only; text drag and drop is yet to come. *** This bug has been marked as a duplicate of bug 49981 ***",FUTURE PLAN 231890,VisualEditor: Add the ability to drag highlighted text around with the mouse,Neat! Thanks :),task_subcomment,Neat! Thanks :),SOLUTION USAGE 231886,VisualEditor: Add the ability to drag highlighted text around with the mouse,"Good news - we've already got this planned as part of the beta - see bug 41150. Marking as a dupe. *** This bug has been marked as a duplicate of bug 41150 ***",task_subcomment,"Good news - we've already got this planned as part of the beta - see bug 41150. Marking as a dupe. *** This bug has been marked as a duplicate of bug 41150 ***",ACTION ON ISSUE 51475,Red links show as blue links in VisualEditor,"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",task_description,"When editing for example URL with the VisualEditor, all the red links are shown as blue links. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 231186,Red links show as blue links in VisualEditor,"Hey, this is a duplicate of bug 37901 - unfortunately, this depends on hinting in Parsoid (bug 37902) which is not yet done. *** This bug has been marked as a duplicate of bug 37901 ***",task_subcomment,"Hey, this is a duplicate of bug 37901 - unfortunately, this depends on hinting in Parsoid (bug 37902) which is not yet done. *** This bug has been marked as a duplicate of bug 37901 ***",BUG REPRODUCTION 51418,new schedule for Jenkins jobs,"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",task_description,"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",FUTURE PLAN 252487,new schedule for Jenkins jobs,"Fixed in https://gerrit.wikimedia.org/r/#/c/69865/ If there is still something to be done here, reopen the bug.",task_subcomment,"Fixed in URL If there is still something to be done here, reopen the bug.",SOLUTION USAGE 252482,new schedule for Jenkins jobs,"Actually, upon reflection, I think we can support the weekly releases better, and move toward even faster release cycles perhaps by something like this: Builds for beta labs to run several times per day. Possibly run Chrome/FF builds more often than IE builds for speed. Builds for test2 to match deployments to test2/mw.o depending on features tested e.g. VisualEditor. Builds for production to match deployments to prod. ""Sufficiently advanced testing is indistinguishable from monitoring."" Builds for mobile TBD.",task_subcomment,"Actually, upon reflection, I think we can support the weekly releases better, and move toward even faster release cycles perhaps by something like this: Builds for beta labs to run several times per day. Possibly run Chrome/FF builds more often than IE builds for speed. Builds for test2 to match deployments to test2/mw.o depending on features tested e.g. VisualEditor. Builds for production to match deployments to prod. ""Sufficiently advanced testing is indistinguishable from monitoring."" Builds for mobile TBD.",SOLUTION DISCUSSION 51384,VisualEditor: Linking to an image results in the image being loaded,"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}",task_description,"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}",BUG REPRODUCTION 250172,VisualEditor: Linking to an image results in the image being loaded," *** This bug has been marked as a duplicate of bug 48387 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 48387 ***",ACTION ON ISSUE 51336,Inconsistency in the URL (veaction=edit disappears),"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",task_description,"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",BUG REPRODUCTION 247540,Inconsistency in the URL (veaction=edit disappears),"This is being done as part of bug 43844. Instead of letting it stay, we're going to enforce it even when not there. veaction=edit was originally (and still is) only used to start VisualEditor by url. When starting it from within MediaWiki by clicking ""Edit"" when reading an article, it never used veaction=edit. Bug 43844 asks for consistent url reflection of state in both directions. *** This bug has been marked as a duplicate of bug 43844 ***",task_subcomment,"This is being done as part of bug 43844. Instead of letting it stay, we're going to enforce it even when not there. veaction=edit was originally (and still is) only used to start VisualEditor by url. When starting it from within MediaWiki by clicking ""Edit"" when reading an article, it never used veaction=edit. Bug 43844 asks for consistent url reflection of state in both directions. *** This bug has been marked as a duplicate of bug 43844 ***",ACTION ON ISSUE 51084,Configure beta and MW.org to have $wgVisualEditorEnableExperimentalCode = true;,"VisualEditor's new features should be exposed for testing outside of our local development environments. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"VisualEditor's new features should be exposed for testing outside of our local development environments. -------------------------- **Version**: unspecified **Severity**: normal",FUTURE PLAN 232785,Configure beta and MW.org to have $wgVisualEditorEnableExperimentalCode = true;,Done on 2013-06-06.,task_subcomment,Done on 2013-06-06.,ACTION ON ISSUE 232781,Configure beta and MW.org to have $wgVisualEditorEnableExperimentalCode = true;,"(In reply to comment #1) > And the test and MW.org wikis. Per Timo's comments, only on MW.org not test.",task_subcomment,"(In reply to comment #1) QUOTE Per Timo's comments, only on MW.org not test.",ACTION ON ISSUE 232776,Configure beta and MW.org to have $wgVisualEditorEnableExperimentalCode = true;,And the test and MW.org wikis.,task_subcomment,And the test and MW.org wikis.,SOLUTION USAGE 50893,Various submodules in mediawiki/extensions are not being automatically updated,"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",task_description,"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: URL 2. Commit to Gerrit: URL (line 1661) 3. Still not updated in he.wikipedia: URL -------------------------- **Version**: wmf-deployment **Severity**: normal",BUG REPRODUCTION 226321,Various submodules in mediawiki/extensions are not being automatically updated,"The issue is on Gerrit side. The check-sync.sh of mediawiki/extensions.git let us detect such issue. Follow up on bug 49846 mediawiki/extensions.git does not update some extensions *** This bug has been marked as a duplicate of bug 49846 ***",task_subcomment,"The issue is on Gerrit side. The check-sync.sh of mediawiki/extensions.git let us detect such issue. Follow up on bug 49846 mediawiki/extensions.git does not update some extensions *** This bug has been marked as a duplicate of bug 49846 ***",BUG REPRODUCTION 226316,Various submodules in mediawiki/extensions are not being automatically updated,"So VisualEditor was fixed with some manual database poking, and a number of the others seem to have been fixed too. Thanks ^demon! On the other hand, a number of others seem to be newly broken. The current list is: AutoCreateCategoryPages Bootstrap Campaigns CirrusSearch CommunityTwitter CoreEvents EImage Less OpenStreetMapSlippyMap PerPageLicense QuickResponse TimelineTable WikibaseDataModel WikibaseQueryEngine If you have a fully checked-out version of mediawiki/extensions (git pull && git submodule update --init --recursive), this bash script should tell you the submodules that aren't at master: for m in `sed -n 's/\[submodule ""\(.*\)""\]/\1/p' .gitmodules | sort`; do ( cd $m; A=`git log -1 --format=""%h %ci %s""`; B=`git log -1 --format=""%h %ci %s"" origin/master`; [ ""$A"" = ""$B"" ] || echo $m ); done Of course, that won't catch anything that hasn't had a commit since being broken, if such a state is possible. If you want to see info on the actual commits, BTW, you can change 'echo $m' in there to something like 'echo -e ""$m\n $A\n $B""'.",task_subcomment,"So VisualEditor was fixed with some manual database poking, and a number of the others seem to have been fixed too. Thanks ^demon! On the other hand, a number of others seem to be newly broken. The current list is: AutoCreateCategoryPages Bootstrap Campaigns CirrusSearch CommunityTwitter CoreEvents EImage Less OpenStreetMapSlippyMap PerPageLicense QuickResponse TimelineTable WikibaseDataModel WikibaseQueryEngine If you have a fully checked-out version of mediawiki/extensions (git pull && git submodule update --init --recursive), this bash script should tell you the submodules that aren't at master: for m in CODE; do ( cd $m; A=CODE; B=CODE; [ ""$A"" = ""$B"" ] || echo $m ); done Of course, that won't catch anything that hasn't had a commit since being broken, if such a state is possible. If you want to see info on the actual commits, BTW, you can change 'echo $m' in there to something like 'echo -e ""$m\n $A\n $B""'.",BUG REPRODUCTION 226310,Various submodules in mediawiki/extensions are not being automatically updated,"(In reply to comment #0) > For example, let's take the message > Visualeditor-linkinspector-suggest-matching-page: That one arrived. (In reply to comment #2) > Also, I did some further checking and found some other submodules also > affected. The full list is: EImage MagicNoCache MyVariables > NamespaceRelations > OpenStreetMapSlippyMap PHPExcel PerPageLicense TimelineTable VisualEditor I don't know if it's related, but the most obvious place where I saw recent changes being unreported is https://github.com/wikimedia/mediawiki-extensions which at some point reported a bunch of extensions as last edited ""6 months ago"" when they obviously weren't.",task_subcomment,"(In reply to comment #0) QUOTE QUOTE That one arrived. (In reply to comment #2) QUOTE QUOTE QUOTE QUOTE I don't know if it's related, but the most obvious place where I saw recent changes being unreported is URL which at some point reported a bunch of extensions as last edited ""6 months ago"" when they obviously weren't.",MOTIVATION 226304,Various submodules in mediawiki/extensions are not being automatically updated,"(In reply to comment #1) > > We'll see if Gerrit change #65818 (manually updating the submodule to master) > will convince the automatic updating to start working again. It didn't. Also, I did some further checking and found some other submodules also affected. The full list is: EImage MagicNoCache MyVariables NamespaceRelations OpenStreetMapSlippyMap PHPExcel PerPageLicense TimelineTable VisualEditor It'll probably take someone either checking Gerrit's logs or digging through Gerrit's code to find out what exactly is making it not update these modules.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE It didn't. Also, I did some further checking and found some other submodules also affected. The full list is: EImage MagicNoCache MyVariables NamespaceRelations OpenStreetMapSlippyMap PHPExcel PerPageLicense TimelineTable VisualEditor It'll probably take someone either checking Gerrit's logs or digging through Gerrit's code to find out what exactly is making it not update these modules.",INVESTIGATION AND EXPLORATION 226296,Various submodules in mediawiki/extensions are not being automatically updated,"The problem seems to be that the VisualEditor submodule in mediawiki/extensions hasn't been being automatically updated for some reason. We'll see if gerrit change 65818 (manually updating the submodule to master) will convince the automatic updating to start working again.",task_subcomment,"The problem seems to be that the VisualEditor submodule in mediawiki/extensions hasn't been being automatically updated for some reason. We'll see if gerrit change 65818 (manually updating the submodule to master) will convince the automatic updating to start working again.",TASK PROGRESS 50669,"VisualEditor misrepresents linked files as embedded inline, when editing","**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",task_description,"**Author:** CODE **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",BUG REPRODUCTION 212529,"VisualEditor misrepresents linked files as embedded inline, when editing"," *** This bug has been marked as a duplicate of bug 48387 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 48387 ***",ACTION ON ISSUE 212525,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Screenshot of markup **Attached**: {F10438}",task_subcomment,"**swalling** wrote: Screenshot of markup **Attached**: {F10438}",SOLUTION DISCUSSION 212519,"VisualEditor misrepresents linked files as embedded inline, when editing","**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",task_subcomment,"**swalling** wrote: Edit mode, with incorrect thumbnails **Attached**: {F10437}",BUG REPRODUCTION 50658,Enable section-editing on 'beta' profile of VisualEditor deployments,"(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",task_description,"(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",SOLUTION USAGE 211833,Enable section-editing on 'beta' profile of VisualEditor deployments,Done today.,task_subcomment,Done today.,TASK PROGRESS 50645,MediaWiki:Visualeditor-feedback-link doesn't use wiki language,"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",task_description,"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: URL english interface: URL This may apply to other messages as well -------------------------- **Version**: unspecified **Severity**: minor",BUG REPRODUCTION 211099,MediaWiki:Visualeditor-feedback-link doesn't use wiki language," *** This bug has been marked as a duplicate of bug 47730 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 47730 ***",ACTION ON ISSUE 50596,VisualEditor expanding image links,"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}",task_description,"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}",BUG REPRODUCTION 233284,VisualEditor expanding image links," *** This bug has been marked as a duplicate of bug 48387 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 48387 ***",ACTION ON ISSUE 50558,"VisualEditor: API doesn't suggest thinks for string length <= 2, so don't show the suggestions box for links/categories/etc.?","Not sure how to proceed on this one. -------------------------- **Version**: unspecified **Severity**: enhancement",task_description,"Not sure how to proceed on this one. -------------------------- **Version**: unspecified **Severity**: enhancement",SOLUTION DISCUSSION 230862,"VisualEditor: API doesn't suggest thinks for string length <= 2, so don't show the suggestions box for links/categories/etc.?",Apparently it does and MW was just being unhelpful. Ignore.,task_subcomment,Apparently it does and MW was just being unhelpful. Ignore.,SOCIAL CONVERSATION 50527,List looks like it has extra empty lines,"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",task_description,"1. Edit URL 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",BUG REPRODUCTION 229016,List looks like it has extra empty lines,"Oh, I see, my bad, I should have checked the wikicode! :-)",task_subcomment,"Oh, I see, my bad, I should have checked the wikicode! :-)",ACTION ON ISSUE 229011,List looks like it has extra empty lines,"This is not a bug; the actual wikitext of the article has multiple lists with (admittedly hard-to-notice) gaps between them: > […] > *20 South Africa 711,000 (2003) > *21 Sweden 639,000 (2004) > > *22 Ukraine 562,000 (1995) > *23 France 544,000 (2003) > *24 Australia 423,000 (1995) > > *25 Portugal 399,000 (2004) > *26 Bulgaria 353,000 (2005) > […] In VisualEditor these gaps between lists are much more prominent because we need to give the user somewhere obvious to insert their cursor, but this is ""behaviour as expected"". Closing as INVALID. (BTW, I just went and fixed the wikitext in a personal capacity, because it was so awful. :-))",task_subcomment,"This is not a bug; the actual wikitext of the article has multiple lists with (admittedly hard-to-notice) gaps between them: QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE In VisualEditor these gaps between lists are much more prominent because we need to give the user somewhere obvious to insert their cursor, but this is ""behaviour as expected"". Closing as INVALID. (BTW, I just went and fixed the wikitext in a personal capacity, because it was so awful. :-))",ACTION ON ISSUE 50523,Parsoid: Expose order of template parameters call,"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",task_description,"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] URL -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION DISCUSSION 228822,Parsoid: Expose order of template parameters call,"Only the name of parameters is significant, the order is a syntactic detail. You can do a numeric sort on numeric parameter names for UI purposes, but generally our API only talks about named parameters.",task_subcomment,"Only the name of parameters is significant, the order is a syntactic detail. You can do a numeric sort on numeric parameter names for UI purposes, but generally our API only talks about named parameters.",SOLUTION DISCUSSION 50489,VisualEditor: Can not paste new link anchor,"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",task_description,"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",BUG REPRODUCTION 226420,VisualEditor: Can not paste new link anchor,"**jiabao.foss** wrote: That's very nice of you! I would love to investigate this bug.",task_subcomment,"**jiabao.foss** wrote: That's very nice of you! I would love to investigate this bug.",CONTRIBUTION AND COMMITMENT 226411,VisualEditor: Can not paste new link anchor,"(In reply to comment #4) > Sorry that I did not know the link inspector could be rich text. Now looking > forward to the new deployment of VE. It will be nice to read the solution, on > the problem which I have worked on but did not get a good solution. Thank you > for the reviews and explanations. I learned a lot from this attempt. :) Thank you for trying! If you want to get your teeth into something in VisualEditor relatively self-contained, but still touching on a considerable amount of the codebase (and which would be really great to have done), bug 47328 could be a good challenge. Will leave a comment there suggesting an approach.",task_subcomment,"(In reply to comment #4) QUOTE QUOTE QUOTE QUOTE Thank you for trying! If you want to get your teeth into something in VisualEditor relatively self-contained, but still touching on a considerable amount of the codebase (and which would be really great to have done), bug 47328 could be a good challenge. Will leave a comment there suggesting an approach.",ACTION ON ISSUE 226402,VisualEditor: Can not paste new link anchor,"**jiabao.foss** wrote: Sorry that I did not know the link inspector could be rich text. Now looking forward to the new deployment of VE. It will be nice to read the solution, on the problem which I have worked on but did not get a good solution. Thank you for the reviews and explanations. I learned a lot from this attempt. :)",task_subcomment,"**jiabao.foss** wrote: Sorry that I did not know the link inspector could be rich text. Now looking forward to the new deployment of VE. It will be nice to read the solution, on the problem which I have worked on but did not get a good solution. Thank you for the reviews and explanations. I learned a lot from this attempt. :)",SOLUTION USAGE 226394,VisualEditor: Can not paste new link anchor,"Yeah, sorry about this; I was behind in triaging bugs and didn't get to this in time. It's in fact actually a duplicate of an already-fixed bug that went out in wmf4 (but isn't yet deployed on enwiki - that will happen on Monday 20 May). *** This bug has been marked as a duplicate of bug 48195 ***",task_subcomment,"Yeah, sorry about this; I was behind in triaging bugs and didn't get to this in time. It's in fact actually a duplicate of an already-fixed bug that went out in wmf4 (but isn't yet deployed on enwiki - that will happen on Monday 20 May). *** This bug has been marked as a duplicate of bug 48195 ***",ACTION ON ISSUE 226383,VisualEditor: Can not paste new link anchor,"Unfortunately this bug didn't get triaged in time, and I worry that you may have spent a lot of time working on a solution for a no-longer-existing problem. The bug here has to do with pasting into the middle of a link not taking on the proper annotations. This appears to be fixed in master, and production is somewhat behind that. The solution being offered here ( I9ae4aeed6099cbe9affdc2aa83045121bc0b8669 ) adds a ""display text"" input to the inspector - but I think this patch overlooks some important UX and technical issues. We deliberately do not want to have a text field in the inspector for the display text, for a couple of reasons. 1. The ""display text"" isn't just plain text, it could include formatting, templates, images, etc. This isn't going to work in a single line text input. 2. Users already have a way to change the display text (or non-text) content, and if there are bugs there, we should resolve them there.",task_subcomment,"Unfortunately this bug didn't get triaged in time, and I worry that you may have spent a lot of time working on a solution for a no-longer-existing problem. The bug here has to do with pasting into the middle of a link not taking on the proper annotations. This appears to be fixed in master, and production is somewhat behind that. The solution being offered here ( I9ae4aeed6099cbe9affdc2aa83045121bc0b8669 ) adds a ""display text"" input to the inspector - but I think this patch overlooks some important UX and technical issues. We deliberately do not want to have a text field in the inspector for the display text, for a couple of reasons. 1. The ""display text"" isn't just plain text, it could include formatting, templates, images, etc. This isn't going to work in a single line text input. 2. Users already have a way to change the display text (or non-text) content, and if there are bugs there, we should resolve them there.",SOLUTION DISCUSSION 226378,VisualEditor: Can not paste new link anchor,"**jiabao.foss** wrote: I have investigated this bug. When looking at the use case for pasting text as you insert it into the hyperlink you need to also consider other formatting being pasted in. In other editors you can see that the link also splits leaving the text plain. This is because if you pasted for example a table or a section into the center of a link it cant accept this as part of the link itself and must be split. The solution I will work on is add a way to edit the displayed hyperlink text while the linkinspector dialog is open. this will allow users to paste box complex links and displayed text when using visualeditor.",task_subcomment,"**jiabao.foss** wrote: I have investigated this bug. When looking at the use case for pasting text as you insert it into the hyperlink you need to also consider other formatting being pasted in. In other editors you can see that the link also splits leaving the text plain. This is because if you pasted for example a table or a section into the center of a link it cant accept this as part of the link itself and must be split. The solution I will work on is add a way to edit the displayed hyperlink text while the linkinspector dialog is open. this will allow users to paste box complex links and displayed text when using visualeditor.",SOLUTION DISCUSSION 50471,VisualEditor adds ↵ when editing user .js and .css pages,"**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}",task_description,"**Author:** CODE **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}",BUG REPRODUCTION 225367,VisualEditor adds ↵ when editing user .js and .css pages,"Happily, we've just last week disabled editing of JS and CSS pages (the code will be deployed to enwiki on Monday 20 May). *** This bug has been marked as a duplicate of bug 47456 ***",task_subcomment,"Happily, we've just last week disabled editing of JS and CSS pages (the code will be deployed to enwiki on Monday 20 May). *** This bug has been marked as a duplicate of bug 47456 ***",ACTION ON ISSUE 50433,VisualEditor link tool incorrectly shows a red link,"VisualEditor link dialog box incorrectly showing red text, 2013-05-13 Go to . 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}",task_description,"VisualEditor link dialog box incorrectly showing red text, 2013-05-13 Go to Error: see attached screenshot -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F10756}",task_description,"VisualEditor message key exposed on mediawiki.org, 2013-05-13 URL: is not in MW.org's message file; need to do a message purge?,task_subcomment,Looks like is not in MW.org's message file; need to do a message purge?,TASK PROGRESS 50316,"VisualEditor: When the edit tab is replaced it breaks active/selected states and doesn't replace ""Create"" tabs properly.","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",task_description,"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",BUG REPRODUCTION 216336,"VisualEditor: When the edit tab is replaced it breaks active/selected states and doesn't replace ""Create"" tabs properly.","This is a dupe of three different bugs, but I'll settle for the obvious one. :-) (A prior search when you're reporting a bug does help avoid this! :-)) *** This bug has been marked as a duplicate of bug 47452 ***",task_subcomment,"This is a dupe of three different bugs, but I'll settle for the obvious one. :-) (A prior search when you're reporting a bug does help avoid this! :-)) *** This bug has been marked as a duplicate of bug 47452 ***",ACTION ON ISSUE 50179,Parsoid: HTML comment with immediately following table has newline split removed,"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",task_description,"As per Subbu's report. (The corrupted table is going to be a different bug.) -------------------------- **Version**: unspecified **Severity**: trivial **URL**: URL",BUG REPRODUCTION 208134,Parsoid: HTML comment with immediately following table has newline split removed,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE 208127,Parsoid: HTML comment with immediately following table has newline split removed,Fixed in production.,task_subcomment,Fixed in production.,SOLUTION USAGE 208120,Parsoid: HTML comment with immediately following table has newline split removed,Related URL: https://gerrit.wikimedia.org/r/62546 (Gerrit Change If16dda01058715acee8df347b2b9c4da84609113),task_subcomment,Related URL: GERRIT_URL (Gerrit Change If16dda01058715acee8df347b2b9c4da84609113),TASK PROGRESS 208111,Parsoid: HTML comment with immediately following table has newline split removed,I am still getting a clean diff with Chromium (and &debug=true to work around current VE breakage). Can you point out any pages that have a dirty diff both in FF and Chrome?,task_subcomment,I am still getting a clean diff with Chromium (and &debug=true to work around current VE breakage). Can you point out any pages that have a dirty diff both in FF and Chrome?,BUG REPRODUCTION 208101,Parsoid: HTML comment with immediately following table has newline split removed,"(In reply to comment #5) > Those were FF-specific, which points to client-side issues. Are they now an > issue independent of the browser? Actually, that bit wasn't FF-specific, it was happening in Chrome as well (and I can confirm that it still does).",task_subcomment,"(In reply to comment #5) QUOTE QUOTE Actually, that bit wasn't FF-specific, it was happening in Chrome as well (and I can confirm that it still does).",BUG REPRODUCTION 208094,Parsoid: HTML comment with immediately following table has newline split removed,"Those were FF-specific, which points to client-side issues. Are they now an issue independent of the browser?",task_subcomment,"Those were FF-specific, which points to client-side issues. Are they now an issue independent of the browser?",INVESTIGATION AND EXPLORATION 208087,Parsoid: HTML comment with immediately following table has newline split removed,"(In reply to comment #3) > Can you link to the original report? The midden of bug 47712.",task_subcomment,"(In reply to comment #3) QUOTE The midden of bug 47712.",ACTION ON ISSUE 208081,Parsoid: HTML comment with immediately following table has newline split removed,Can you link to the original report?,task_subcomment,Can you link to the original report?,ACTION ON ISSUE 208074,Parsoid: HTML comment with immediately following table has newline split removed,"(In reply to comment #1) > I get a JS error when trying to preview the diff in that page using FF: > [13:44:04.016] 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 Bug 48181.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Bug 48181.",ACTION ON ISSUE 208068,Parsoid: HTML comment with immediately following table has newline split removed,"I get a JS error when trying to preview the diff in that page using FF: [13:44:04.016] 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",task_subcomment,"I get a JS error when trying to preview the diff in that page using FF: [13:44:04.016] Error: toDomElements() failed to return an array when converting element of type alienBlock @ URL",BUG REPRODUCTION 50110,VisualEditor: Adjacent annotations which are equal by name but not reference do not serialise correctly.,"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.: Bold on load textadded text Which Parsoid converts to '''Bold on load text''''''added text''' -------------------------- **Version**: unspecified **Severity**: normal",task_description,"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.: Bold on load textadded text Which Parsoid converts to '''Bold on load text''''''added text''' -------------------------- **Version**: unspecified **Severity**: normal",INVESTIGATION AND EXPLORATION 229423,VisualEditor: Adjacent annotations which are equal by name but not reference do not serialise correctly.,Merged into master.,task_subcomment,Merged into master.,TASK PROGRESS 229419,VisualEditor: Adjacent annotations which are equal by name but not reference do not serialise correctly.,Related URL: https://gerrit.wikimedia.org/r/62352 (Gerrit Change I93586919002c78732228e08b134e67e1a94f8ad7),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I93586919002c78732228e08b134e67e1a94f8ad7),TASK PROGRESS 49860,VisualEditor: Extra tags got inserted causing infobox layout to be broken,"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 and
    . 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",task_description,"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 . 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",BUG REPRODUCTION 233774,VisualEditor: {{clr}} prevents user from editing content," *** This bug has been marked as a duplicate of bug 50551 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50551 ***",ACTION ON ISSUE 233769,VisualEditor: {{clr}} prevents user from editing content,"This is related to bug 51933 - an excessively large transclusion box prevents accessing an item it overlaps. It's not identical though as that bug relates to other templates and this to tables, so I'll leave the decision whether to merge up to someone more knowledgeable.",task_subcomment,"This is related to bug 51933 - an excessively large transclusion box prevents accessing an item it overlaps. It's not identical though as that bug relates to other templates and this to tables, so I'll leave the decision whether to merge up to someone more knowledgeable.",BUG REPRODUCTION 54421,"VisualEditor: Link suggestions sometimes too foreceful, can't select the target you want.","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",task_description,"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",BUG REPRODUCTION 233233,"VisualEditor: Link suggestions sometimes too foreceful, can't select the target you want.","Elitre was 25 seconds faster than you ;) *** This bug has been marked as a duplicate of bug 52420 ***",task_subcomment,"Elitre was 25 seconds faster than you ;) *** This bug has been marked as a duplicate of bug 52420 ***",ACTION ON ISSUE 54410,VisualEditor: Undoing a larger cut restores selection incorrectly,"- Chrome 30 (canary) - https://en.wikipedia.org/w/index.php?title=Narayana_Gosain_Temple&oldid=565414421&veaction=edit When selecting the following: > > 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 > > \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 NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar. > h2.References > references. > \n > \n > h2.External 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 NH5 running between Chennai and Howrah. Nearest railhead is Jajpur Keonjhar Road or Byasanagar. > h2.References > references. > \n > \n > h2.External links -------------------------- **Version**: unspecified **Severity**: normal",task_description,"- Chrome 30 (canary) - URL When selecting the following: QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE .. and cutting it, and then ctrl-Z. It restores both content and selection properly When selecting the following: QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE .. and cutting it and then ctrl-Z. It restores the content properly, but the selection is restored only within the first paragraph: QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION USAGE 257652,VisualEditor: Undoing a larger cut restores selection incorrectly,This was fixed in the selection re-writes.,task_subcomment,This was fixed in the selection re-writes.,SOLUTION USAGE 54374,Stray bullet points around template and strange editing around them,"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}",task_description,"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] URL [2] URL -------------------------- **Version**: unspecified **Severity**: normal **URL**: URL **Attached**: {F11912}",BUG REPRODUCTION 255600,Stray bullet points around template and strange editing around them,"This is a known tidy issue, so marking as a duplicate. *** This bug has been marked as a duplicate of bug 47673 ***",task_subcomment,"This is a known tidy issue, so marking as a duplicate. *** This bug has been marked as a duplicate of bug 47673 ***",ACTION ON ISSUE 255598,Stray bullet points around template and strange editing around them,"This is a duplicate of a Parsoid bug that has been WONTFIX'ed, I believe (but I can't find right now) - Gabriel, can you remember which one? (In reply to comment #4) > FWIW, even Special:ExpandTemplates seems to be affected by this bug! … which is a sign that you're abusing wikitext, and should stop trying to get this to work. :-) Special:ExpandTemplates has nothing to do with VisualEditor or Parsoid.",task_subcomment,"This is a duplicate of a Parsoid bug that has been WONTFIX'ed, I believe (but I can't find right now) - Gabriel, can you remember which one? (In reply to comment #4) QUOTE … which is a sign that you're abusing wikitext, and should stop trying to get this to work. :-) Special:ExpandTemplates has nothing to do with VisualEditor or Parsoid.",ACTION ON ISSUE 255595,Stray bullet points around template and strange editing around them,"I believe I found the root cause - demonstrated by a minimal test case: https://www.mediawiki.org/wiki/User:Skalman/bullet_point_test Wikitext of template: * {{{1}}} Wikitext of page: * {{template|Hello there}} Expected output (the way the traditional parser handles it): * Hello there Note that a naive wikitext template expander would produce: * * Hello there To me, this now seems to be a problem with the data model. FWIW, even Special:ExpandTemplates seems to be affected by this bug!",task_subcomment,"I believe I found the root cause - demonstrated by a minimal test case: URL Wikitext of template: * {{{1}}} Wikitext of page: * {{template|Hello there}} Expected output (the way the traditional parser handles it): * Hello there Note that a naive wikitext template expander would produce: * * Hello there To me, this now seems to be a problem with the data model. FWIW, even Special:ExpandTemplates seems to be affected by this bug!",INVESTIGATION AND EXPLORATION 255589,Stray bullet points around template and strange editing around them,Reproduced in Chrome 28 and Opera 12.16.,task_subcomment,Reproduced in Chrome 28 and Opera 12.16.,OBSERVED BUG BEHAVIOR 255583,Stray bullet points around template and strange editing around them,"And further weirdness: When I add the text 'ABC' to the first of the now three bullet points I get the following wikitext: * {{IMDb-titel|id=0105928}}ABC * ''[ackorna''' (originaltitel ''2 Stupid Byrackorna]'' på [[Internet Movie Database]] (engelska) *",task_subcomment,"And further weirdness: When I add the text 'ABC' to the first of the now three bullet points I get the following wikitext: * {{IMDb-titel|id=0105928}}ABC * ''[ackorna''' (originaltitel ''2 Stupid Byrackorna]'' på [[Internet Movie Database]] (engelska) *",SOLUTION DISCUSSION 255577,Stray bullet points around template and strange editing around them,This is probably a ContentEditable problem.,task_subcomment,This is probably a ContentEditable problem.,BUG REPRODUCTION 54364,drag and drop for text,"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",task_description,"Request to introduce drag and drop for text passages; there are also bugs for images around (obviously). Report: URL -------------------------- **Version**: unspecified **Severity**: enhancement",SOLUTION DISCUSSION 254818,drag and drop for text,"There's already bug 49981 for drag-and-drop of content in general; I don't think this is sufficiently different (drag-and-drop of text is not sufficiently distinct from drag-and-drop of non-text to be worth splitting out), so merging. *** This bug has been marked as a duplicate of bug 49981 ***",task_subcomment,"There's already bug 49981 for drag-and-drop of content in general; I don't think this is sufficiently different (drag-and-drop of text is not sufficiently distinct from drag-and-drop of non-text to be worth splitting out), so merging. *** This bug has been marked as a duplicate of bug 49981 ***",ACTION ON ISSUE 54307,Contents of pre-existing transclusion saved to article adjacent to transclusion,"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:
    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",task_description,"URL This may be a template that got subst'd in VisualEditor. It produces this text:
    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",SOLUTION USAGE 251756,Contents of pre-existing transclusion saved to article adjacent to transclusion,I believe all these issues were fixed months ago (sorry for very slow triage).,task_subcomment,I believe all these issues were fixed months ago (sorry for very slow triage).,ISSUE CONTENT MANAGEMENT 251750,Contents of pre-existing transclusion saved to article adjacent to transclusion,"That's the contents of the {{Przypisy}} template. It looks like they ""spilled out"". Parsoid issue?",task_subcomment,"That's the contents of the {{Przypisy}} template. It looks like they ""spilled out"". Parsoid issue?",OBSERVED BUG BEHAVIOR 54291,VisualEditor: Editing surface displays non-existent spaces after bullet points in Thai Wikipedia,"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}",task_description,"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}",BUG REPRODUCTION 250586,VisualEditor: Editing surface displays non-existent spaces after bullet points in Thai Wikipedia,"This is because the Thai Wikipedia has this CSS in its Common.css: | /* A request by octahedron80 19:13, 7 ธันวาคม 2554 (ICT) */ | .mw-content-ltr dd, .mw-content-rtl .mw-content-ltr dd { | margin-left: 2.5em; | } | .mw-content-ltr ul, .mw-content-rtl .mw-content-ltr ul { | margin-left: 2.5em; | } | .mw-content-ltr ol, .mw-content-rtl .mw-content-ltr ol { | margin-left: 2.5em; | } There's no justification for it beyond who requested it, so I can't judge whether the purpose it serves is sufficient, but it's deliberate. As this is based on local wiki configuration, marking as INVALID.",task_subcomment,"This is because the Thai Wikipedia has this CSS in its Common.css: | /* A request by octahedron80 19:13, 7 ธันวาคม 2554 (ICT) */ | .mw-content-ltr dd, .mw-content-rtl .mw-content-ltr dd { | margin-left: 2.5em; | } | .mw-content-ltr ul, .mw-content-rtl .mw-content-ltr ul { | margin-left: 2.5em; | } | .mw-content-ltr ol, .mw-content-rtl .mw-content-ltr ol { | margin-left: 2.5em; | } There's no justification for it beyond who requested it, so I can't judge whether the purpose it serves is sufficient, but it's deliberate. As this is based on local wiki configuration, marking as INVALID.",ACTION ON ISSUE 250577,VisualEditor: Editing surface displays non-existent spaces after bullet points in Thai Wikipedia,"**KaewWiki** wrote: (In reply to comment #0) > Created attachment 13022 [details] > 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 Also in the same image, at the end of reference section (in Thai {{รายการอ้างอิง}}) and immediately before {{stub}} (in Thai {{โครงกฎหมาย}}), VE displayed additional blank line where it should not do so. **Attached**: {F11736}",task_subcomment,"**KaewWiki** wrote: (In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Also in the same image, at the end of reference section (in Thai {{รายการอ้างอิง}}) and immediately before {{stub}} (in Thai {{โครงกฎหมาย}}), VE displayed additional blank line where it should not do so. **Attached**: {F11736}",BUG REPRODUCTION 250569,VisualEditor: Editing surface displays non-existent spaces after bullet points in Thai Wikipedia,"Example page on th.wp: https://th.wikipedia.org/wiki/กฎหมายปิดปาก?veaction=edit I can't reproduce this with Thai text on en.wp. See for example https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&oldid=575310209&veaction=edit",task_subcomment,"Example page on th.wp: URL I can't reproduce this with Thai text on en.wp. See for example URL",BUG REPRODUCTION 54285,VisualEditor: Following links in image captions that have a large value takes over media settings dialog which can't then be closed,"link target takes over media settings dialog If text has a size specified, e.g , 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. text with a [[link]]. 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}",task_description,"link target takes over media settings dialog If text has a size specified, e.g , 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. text with a [[link]]. 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}",BUG REPRODUCTION 250209,VisualEditor: Following links in image captions that have a large value takes over media settings dialog which can't then be closed,"This has the same root cause as bug 51778, despite the names; merging. *** This bug has been marked as a duplicate of bug 51778 ***",task_subcomment,"This has the same root cause as bug 51778, despite the names; merging. *** This bug has been marked as a duplicate of bug 51778 ***",ACTION ON ISSUE 250200,VisualEditor: Following links in image captions that have a large value takes over media settings dialog which can't then be closed,Cryptic C62 and en.wp has noted that he can replicate this in Firefox 22 and Chrome 28 running on Windows Vista. Both they and I use the monobook skin.,task_subcomment,Cryptic C62 and en.wp has noted that he can replicate this in Firefox 22 and Chrome 28 running on Windows Vista. Both they and I use the monobook skin.,BUG REPRODUCTION 250194,VisualEditor: Following links in image captions that have a large value takes over media settings dialog which can't then be closed,"Steps to reproduce: 1. Edit https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox2&oldid=566460073#New_section in VE 2. Click on the last image and open the media settings dialog 3. Left click the link above the ""can only edit in source"" bar. This happens in Firefox 22 on Linux, I can't test in other browsers/OSes.",task_subcomment,"Steps to reproduce: 1. Edit URL in VE 2. Click on the last image and open the media settings dialog 3. Left click the link above the ""can only edit in source"" bar. This happens in Firefox 22 on Linux, I can't test in other browsers/OSes.",BUG REPRODUCTION 54270,VisualEditor should be themeable by the user with custom CSS,"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",task_description,"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",SOLUTION USAGE 249376,VisualEditor should be themeable by the user with custom CSS,"**gryllida** wrote: I understand you expect folks to either 1) look into having existing themes change the VisualEditor appearance to fit their style, or 2) to look into using CSS. As the latter is not user-friendly for non-technical users I will look into the former. Thank you.",task_subcomment,"**gryllida** wrote: I understand you expect folks to either 1) look into having existing themes change the VisualEditor appearance to fit their style, or 2) to look into using CSS. As the latter is not user-friendly for non-technical users I will look into the former. Thank you.",SOLUTION DISCUSSION 249373,VisualEditor should be themeable by the user with custom CSS,"(In reply to comment #8) > [...] when the rest of MediaWiki is designed to be consistent. :-)",task_subcomment,"(In reply to comment #8) QUOTE :-)",ACTION ON ISSUE 249371,VisualEditor should be themeable by the user with custom CSS,"(In reply to comment #5) > My original query was in making different styles available for an average > user, who has no CSS experience. Then that's a question for MediaWiki core, not VisualEditor; VisualEditor just inherits its styling from MediaWiki. Certainly, we are not going to build a custom-styling tool just for VisualEditor when the rest of MediaWiki is designed to be consistent.",task_subcomment,"(In reply to comment #5) QUOTE QUOTE Then that's a question for MediaWiki core, not VisualEditor; VisualEditor just inherits its styling from MediaWiki. Certainly, we are not going to build a custom-styling tool just for VisualEditor when the rest of MediaWiki is designed to be consistent.",SOLUTION DISCUSSION 249368,VisualEditor should be themeable by the user with custom CSS,"Hey James, I am reopening this to understand whether Gryllida's concerns can/should be addressed, and because the user understands, from the logs of a recent office hour, that you welcome feedback from users about this topic. Gryllida is asking for a set of themes for the Toolbar from which the user can choose the one he/she wants (and provided examples in comment #2). Other users instead were hoping that graphic solutions that are now possible by changing one's CSS are made more easily accessible in VE itself. I for one am not really good at editing my CSS page, but I could easily check a box that lets me choose a different background color that makes it more obvious when I'm VEditing (and would gladly do so). So there are probably 2 different requests here, and I can split them if one of them can be worked on. Thanks :)",task_subcomment,"Hey James, I am reopening this to understand whether Gryllida's concerns can/should be addressed, and because the user understands, from the logs of a recent office hour, that you welcome feedback from users about this topic. Gryllida is asking for a set of themes for the Toolbar from which the user can choose the one he/she wants (and provided examples in comment #2). Other users instead were hoping that graphic solutions that are now possible by changing one's CSS are made more easily accessible in VE itself. I for one am not really good at editing my CSS page, but I could easily check a box that lets me choose a different background color that makes it more obvious when I'm VEditing (and would gladly do so). So there are probably 2 different requests here, and I can split them if one of them can be worked on. Thanks :)",SOLUTION DISCUSSION 249365,VisualEditor should be themeable by the user with custom CSS,"**gryllida** wrote: Elitre, please file a new bug, my query you pasted does not belong here.",task_subcomment,"**gryllida** wrote: Elitre, please file a new bug, my query you pasted does not belong here.",ACTION ON ISSUE 249360,VisualEditor should be themeable by the user with custom CSS,"**gryllida** wrote: My original query was in making different styles available for an average user, who has no CSS experience.",task_subcomment,"**gryllida** wrote: My original query was in making different styles available for an average user, who has no CSS experience.",SOLUTION DISCUSSION 249355,VisualEditor should be themeable by the user with custom CSS,"I'm entirely unsure what this is asking for. VE already inherits users' CSS, which lets people change the CSS as they see fit - as John Broughton's script shows. Marking as ""INVALID"", but happy to re-open if people can explain what different from the above this is asking for.",task_subcomment,"I'm entirely unsure what this is asking for. VE already inherits users' CSS, which lets people change the CSS as they see fit - as John Broughton's script shows. Marking as ""INVALID"", but happy to re-open if people can explain what different from the above this is asking for.",ACTION ON ISSUE 249352,VisualEditor should be themeable by the user with custom CSS,"An example of how users might want to change the way they see VE: https://en.wikipedia.org/wiki/User:John_Broughton/common.css (an easier way to set a background color for VE is being requested).",task_subcomment,"An example of how users might want to change the way they see VE: URL (an easier way to set a background color for VE is being requested).",POTENTIAL NEW ISSUES AND REQUESTS 249348,VisualEditor should be themeable by the user with custom CSS,"**gryllida** wrote: ( Illustrations: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=570246873#Toolbar_icons_style )",task_subcomment,"**gryllida** wrote: ( Illustrations: URL )",ACTION ON ISSUE 249344,VisualEditor should be themeable by the user with custom CSS,"Gryllida adds, <>",task_subcomment,"Gryllida adds, <>",SOLUTION DISCUSSION 54269,VisualEditor: References not saved,"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}",task_description,"References 5-8 were not saved At URL 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}",BUG REPRODUCTION 249314,VisualEditor: References not saved,"I can't reproduce this now, so it seems likely this was a duplicate of now-fixed Bug 52228 *** This bug has been marked as a duplicate of bug 52228 ***",task_subcomment,"I can't reproduce this now, so it seems likely this was a duplicate of now-fixed Bug 52228 *** This bug has been marked as a duplicate of bug 52228 ***",BUG REPRODUCTION 54266,Parsoid or VisualEditor: nowiki added around space following HTML comment,"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",task_description,"At line 138 of URL 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",BUG REPRODUCTION 249210,Parsoid or VisualEditor: nowiki added around space following HTML comment," *** This bug has been marked as a duplicate of bug 50758 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50758 ***",ACTION ON ISSUE 54264,VisualEditor: Wikitext insertion warning needs to be more visible,"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",task_description,"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",SOLUTION USAGE 249118,VisualEditor: Wikitext insertion warning needs to be more visible,"WONTFIX. It's currently blocking save, doesn't disappear until clicked, and in the standard place for interactive notifications in MediaWiki; moving these around for the mouse (or cursor) could get very ugly and confusing, and the advantage isn't so significant that it's worth doing.",task_subcomment,"WONTFIX. It's currently blocking save, doesn't disappear until clicked, and in the standard place for interactive notifications in MediaWiki; moving these around for the mouse (or cursor) could get very ugly and confusing, and the advantage isn't so significant that it's worth doing.",ACTION ON ISSUE 249111,VisualEditor: Wikitext insertion warning needs to be more visible,"Maybe closest to the mouse would be better. If someone edits at the bottom of the displayed content with a large screen, I’m not sure he will see the warning, too far.",task_subcomment,"Maybe closest to the mouse would be better. If someone edits at the bottom of the displayed content with a large screen, I’m not sure he will see the warning, too far.",SOLUTION DISCUSSION 54252,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,"Labeled Section Transclusion (
    Text here
    ) 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",task_description,"Labeled Section Transclusion (
    Text here
    ) 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",BUG REPRODUCTION 248314,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,"LST is heavily used in wikisource, where most parts of pages are wrapped in section tags. Alienation and / or an extension-like visual edit experience would not be ideal there, which is why we are considering supporting
    natively as the HTML5 element it is. Closing as duplicated of bug 47936 for that reason. Please respond there if you feel that this is the wrong approach. *** This bug has been marked as a duplicate of bug 47936 ***",task_subcomment,"LST is heavily used in wikisource, where most parts of pages are wrapped in section tags. Alienation and / or an extension-like visual edit experience would not be ideal there, which is why we are considering supporting
    natively as the HTML5 element it is. Closing as duplicated of bug 47936 for that reason. Please respond there if you feel that this is the wrong approach. *** This bug has been marked as a duplicate of bug 47936 ***",ACTION ON ISSUE 248309,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,"Related: bug 51562 Related: bug 47936 We probably need a single bug that merges all these three.",task_subcomment,"Related: bug 51562 Related: bug 47936 We probably need a single bug that merges all these three.",TASK PROGRESS 248302,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,whoops. misfire.,task_subcomment,whoops. misfire.,ACTION ON ISSUE 248299,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid," *** This bug has been marked as a duplicate of bug 51462 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 51462 ***",ACTION ON ISSUE 248296,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,"For VisualEditor to alienate something, all that is required is for Parsoid to mark it up as something VisualEditor doesn't recognise; right now, Parsoid and VisualEditor are both entirely dumb to the issue. :-)",task_subcomment,"For VisualEditor to alienate something, all that is required is for Parsoid to mark it up as something VisualEditor doesn't recognise; right now, Parsoid and VisualEditor are both entirely dumb to the issue. :-)",SOLUTION DISCUSSION 248295,Recognise Labeled Section Transclusions as mw:Extension/Lst or similar in Parsoid,An example is https://www.mediawiki.org/w/index.php?title=Editor_engagement_experiments/status&oldid=750533,task_subcomment,An example is URL,SOLUTION USAGE 54251,"VisualEditor: Link input widget should not show ""New: (redlink)"" when a redirect exists by that name","Screenshot of problem See screenshot. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11666}",task_description,"Screenshot of problem See screenshot. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F11666}",BUG REPRODUCTION 248262,"VisualEditor: Link input widget should not show ""New: (redlink)"" when a redirect exists by that name"," *** This bug has been marked as a duplicate of bug 50898 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50898 ***",ACTION ON ISSUE 54250,VisualEditor: Add guidance message into the reference dialog to tell a user what to put there,"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",task_description,"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",SOLUTION DISCUSSION 248201,VisualEditor: Add guidance message into the reference dialog to tell a user what to put there,"This feels like the wrong approach. In general, if you have to prompt a user with text telling them what to do, your interface has failed. Bug 50110 (which we want to work on soon) would give users some buttons (or something similar) for a few, recommended templates for the context - and yes, that would be wiki-localised. Consequently, I'm marking this as WONTFIX so we can focus on bug 50110.",task_subcomment,"This feels like the wrong approach. In general, if you have to prompt a user with text telling them what to do, your interface has failed. Bug 50110 (which we want to work on soon) would give users some buttons (or something similar) for a few, recommended templates for the context - and yes, that would be wiki-localised. Consequently, I'm marking this as WONTFIX so we can focus on bug 50110.",ACTION ON ISSUE 54248,Provide a way for the Behavior switches magic words to be inserted.,"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",task_description,"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 URL -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION DISCUSSION 248120,Provide a way for the Behavior switches magic words to be inserted.,"This was later created as bug 56865, but I'm only just triaging this now. Up-merging (unusually) given the history on that one - sorry! *** This bug has been marked as a duplicate of bug 56865 ***",task_subcomment,"This was later created as bug 56865, but I'm only just triaging this now. Up-merging (unusually) given the history on that one - sorry! *** This bug has been marked as a duplicate of bug 56865 ***",ACTION ON ISSUE 54242,VisualEditor: template substituted in,"See https://en.wikipedia.org/w/index.php?title=Cruz_Azul&diff=564888460&oldid=564725284 - very strange. -------------------------- **Version**: unspecified **Severity**: normal",task_description,"See URL - very strange. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 247748,VisualEditor: template substituted in,This was a recurring Parsoid bug which is now fixed; closing. Sorry for slow triage.,task_subcomment,This was a recurring Parsoid bug which is now fixed; closing. Sorry for slow triage.,ACTION ON ISSUE 54218,inserting media into tables,"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",task_description,"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: URL Image: URL The file fails to show up, if you put its name in manually once you reach ""5"" Report: URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 246556,inserting media into tables,"This is actually a duplicate of bug 52782, which has been marked as WONTFIX as the Wikimedia search system is being replaced. Sorry for the slow response. *** This bug has been marked as a duplicate of bug 52782 ***",task_subcomment,"This is actually a duplicate of bug 52782, which has been marked as WONTFIX as the Wikimedia search system is being replaced. Sorry for the slow response. *** This bug has been marked as a duplicate of bug 52782 ***",ACTION ON ISSUE 246548,inserting media into tables,"Confirmed. Typing 'Intel Socket 11' gives a list of images, but not this image. Typing 'Intel Socket 115' gives zero results. The image description is 'Intel core socket 1150, open.' Typing in 'Intel core socket 1150' does show this, and other images, so it doesnt appear to be bug 50018.",task_subcomment,"Confirmed. Typing 'Intel Socket 11' gives a list of images, but not this image. Typing 'Intel Socket 115' gives zero results. The image description is 'Intel core socket 1150, open.' Typing in 'Intel core socket 1150' does show this, and other images, so it doesnt appear to be bug 50018.",MOTIVATION 54212,reference clipboard errors,"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",task_description,"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: URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 246229,reference clipboard errors," *** This bug has been marked as a duplicate of bug 49396 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 49396 ***",ACTION ON ISSUE 54205,VisualEditor: Toolbar should fit on landscape iPad (and average non-maximised windows in general),"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}",task_description,"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}",SOLUTION DISCUSSION 245709,VisualEditor: Toolbar should fit on landscape iPad (and average non-maximised windows in general),"Yes, this is; merging. *** This bug has been marked as a duplicate of bug 51000 ***",task_subcomment,"Yes, this is; merging. *** This bug has been marked as a duplicate of bug 51000 ***",ACTION ON ISSUE 245700,VisualEditor: Toolbar should fit on landscape iPad (and average non-maximised windows in general),Same as bug 51000?,task_subcomment,Same as bug 51000?,BUG REPRODUCTION 245693,VisualEditor: Toolbar should fit on landscape iPad (and average non-maximised windows in general),"Created attachment 13387 Screenshot of two side-by-side VE windows on 1080p screen I see the exact same problem when sizing a window to half of a 1080p HD screen -- circa 960px window width is not uncommon... **Attached**: {F11565}",task_subcomment,"Created attachment 13387 Screenshot of two side-by-side VE windows on 1080p screen I see the exact same problem when sizing a window to half of a 1080p HD screen -- circa 960px window width is not uncommon... **Attached**: {F11565}",BUG REPRODUCTION 54198,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","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",task_description,"Per URL If trying to add a template, only adding content (empty) and click apply, following error is thrown: TypeError: content is undefined URL Line 192 -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 245098,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","(In reply to comment #5) > Doesn't give a error anymore, but API is returning: > > {""warnings"":{""main"":{""*"":""Unrecognized parameter: > 'token'""}},""visualeditor"":{""result"":""success"",""content"":""

    x

    \n\n""}} That warning is unrelated. We're passively passing the authentication token to API requests, even though some API requests don't require a token. This is technical debt we should clean up. Closing bug as fixed/worksforme.",task_subcomment,"(In reply to comment #5) QUOTE QUOTE QUOTE QUOTE That warning is unrelated. We're passively passing the authentication token to API requests, even though some API requests don't require a token. This is technical debt we should clean up. Closing bug as fixed/worksforme.",ACTION ON ISSUE 245094,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","(In reply to comment #1) > 1. Insert Transclusion > 2. Ignore ""New template"" panel in the dialog and go to ""+ [] Add content"" > 3. Type ""x"" > 4. Apply changes 5. Show changes 6. Review your changes Foo + x Bar All works as expected on latest master, and no errors.",task_subcomment,"(In reply to comment #1) QUOTE QUOTE QUOTE QUOTE 5. Show changes 6. Review your changes Foo + x Bar All works as expected on latest master, and no errors.",SOLUTION USAGE 245091,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","Doesn't give a error anymore, but API is returning: {""warnings"":{""main"":{""*"":""Unrecognized parameter: 'token'""}},""visualeditor"":{""result"":""success"",""content"":""

    x

    \n\n""}}",task_subcomment,"Doesn't give a error anymore, but API is returning: {""warnings"":{""main"":{""*"":""Unrecognized parameter: 'token'""}},""visualeditor"":{""result"":""success"",""content"":""

    x

    \n\n""}}",BUG REPRODUCTION 245088,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","(In reply to comment #3) > (In reply to comment #2) > > > > > if (content.params) { > > > > If we had used coffescript instead of plain JS, it would be so simple to > > write > > that as: > > if content?.params > > ... > > > > Now I assume we'll need to do it manually as > > if (typeof content !== ""undefined"" && content !== null && content.params) { > > ... > > } > It's much easier than that, you can just do if ( content && content.params ) > . > No need to use typeof and string comparisons and all that :) > > Really, though, content shouldn't be undefined in the first place. Indeed, guarding it with an if statement for content? itself is undesirable because the error is elsewhere.",task_subcomment,"(In reply to comment #3) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE Indeed, guarding it with an if statement for content? itself is undesirable because the error is elsewhere.",SOLUTION DISCUSSION 245083,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","(In reply to comment #2) > > > > if (content.params) { > > If we had used coffescript instead of plain JS, it would be so simple to > write > that as: > if content?.params > ... > > Now I assume we'll need to do it manually as > if (typeof content !== ""undefined"" && content !== null && content.params) { > ... > } It's much easier than that, you can just do if ( content && content.params ) . No need to use typeof and string comparisons and all that :) Really, though, content shouldn't be undefined in the first place.",task_subcomment,"(In reply to comment #2) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE It's much easier than that, you can just do if ( content && content.params ) . No need to use typeof and string comparisons and all that :) Really, though, content shouldn't be undefined in the first place.",MOTIVATION 245080,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","> > > if (content.params) { If we had used coffescript instead of plain JS, it would be so simple to write that as: if content?.params ... Now I assume we'll need to do it manually as if (typeof content !== ""undefined"" && content !== null && content.params) { ... }",task_subcomment,"QUOTE If we had used coffescript instead of plain JS, it would be so simple to write that as: if content?.params ... Now I assume we'll need to do it manually as if (typeof content !== ""undefined"" && content !== null && content.params) { ... }",SOLUTION DISCUSSION 245075,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'params' of undefined 'content'""","1. Insert Transclusion 2. Ignore ""New template"" panel in the dialog and go to ""+ [] Add content"" 3. Type ""x"" 4. Apply changes 5. > Uncaught TypeError: content is undefined http://bits.wikimedia.org/static-1.22wmf11/extensions/VisualEditor/modules/ve-mw/dm/nodes/ve.dm.MWTransclusionNode.js:192 > ve.dm.MWTransclusionNode.prototype.getWikitext = function() { > var i, len, part, template, param, content = this.getAttribute('mw'), wikitext = ''; > > if (content.params) { > content = {'parts': [{'template': content}]}; > } Uncaught TypeError: Cannot read property 'params' of undefined ve.dm.MWTransclusionNode.getWikitext ve.ce.MWTransclusionNode.generateContents ve.ce.GeneratedContentNode.onUpdate VeCeGeneratedContentNode VeCeMWTransclusionNode VeCeMWTransclusionInlineNode ve.Factory.create ve.ce.BranchNode.onSplice ve.ce.ContentBranchNode.onSplice oo.EventEmitter.emit ve.dm.BranchNode.splice ve.insertIntoArray ve.dm.Document.rebuildNodes ve.dm.DocumentSynchronizer.synchronizers.rebuild ve.dm.DocumentSynchronizer.synchronize ve.dm.TransactionProcessor.process ve.dm.Document.commit ve.dm.Surface.change ve.dm.SurfaceFragment.insertContent ve.ui.MWTransclusionDialog.onClose ve.ui.Window.close (anonymous function) proxy",task_subcomment,"1. Insert Transclusion 2. Ignore ""New template"" panel in the dialog and go to ""+ [] Add content"" 3. Type ""x"" 4. Apply changes 5. > Uncaught TypeError: content is undefined URL QUOTE QUOTE QUOTE QUOTE QUOTE Uncaught TypeError: Cannot read property 'params' of undefined ve.dm.MWTransclusionNode.getWikitext ve.ce.MWTransclusionNode.generateContents ve.ce.GeneratedContentNode.onUpdate VeCeGeneratedContentNode VeCeMWTransclusionNode VeCeMWTransclusionInlineNode ve.Factory.create ve.ce.BranchNode.onSplice ve.ce.ContentBranchNode.onSplice oo.EventEmitter.emit ve.dm.BranchNode.splice ve.insertIntoArray ve.dm.Document.rebuildNodes ve.dm.DocumentSynchronizer.synchronizers.rebuild ve.dm.DocumentSynchronizer.synchronize ve.dm.TransactionProcessor.process ve.dm.Document.commit ve.dm.Surface.change ve.dm.SurfaceFragment.insertContent ve.ui.MWTransclusionDialog.onClose ve.ui.Window.close (anonymous function) proxy",BUG REPRODUCTION 54169,VisualEditor doesn't confirm closing window,"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",task_description,"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",BUG REPRODUCTION 243401,VisualEditor doesn't confirm closing window,Yeah I can confirm as well. Not sure when it started working again.,task_subcomment,Yeah I can confirm as well. Not sure when it started working again.,BUG REPRODUCTION 243398,VisualEditor doesn't confirm closing window,"For the record: going to https://en.wikipedia.org/wiki/Mykola_Labovskyy?veaction=edit and typing anithing, and then closing the browser tab causes the warning ""Are you sure you want to go back to view mode without saving first?""",task_subcomment,"For the record: going to URL and typing anithing, and then closing the browser tab causes the warning ""Are you sure you want to go back to view mode without saving first?""",BUG REPRODUCTION 243394,VisualEditor doesn't confirm closing window,"I'm going to close this as WORKSFORME because it does (and always has), and the bug report gives no details of how to reproduce. Please re-open if you have steps to reproduce. Sorry for very slow triage.",task_subcomment,"I'm going to close this as WORKSFORME because it does (and always has), and the bug report gives no details of how to reproduce. Please re-open if you have steps to reproduce. Sorry for very slow triage.",ACTION ON ISSUE 54155,"VisualEditor: ""Wikitext markup detected"" message should disappear automatically when there's no more wikitext","""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",task_description,"""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",BUG REPRODUCTION 242535,"VisualEditor: ""Wikitext markup detected"" message should disappear automatically when there's no more wikitext"," %%%*** This bug has been marked as a duplicate of bug 51701 ***%%%",task_subcomment," %%%*** This bug has been marked as a duplicate of bug 51701 ***%%%",ACTION ON ISSUE 54125,"VisualEditor - Using ""Select all"" (Ctrl+a) and deleting the selected content afterwards leaves the document uneditable.","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:

    

    -------------------------- **Version**: unspecified **Severity**: normal",task_description,"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:

    

    -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 240932,"VisualEditor - Using ""Select all"" (Ctrl+a) and deleting the selected content afterwards leaves the document uneditable.","This is a duplicate of bug 50947 - merging. *** This bug has been marked as a duplicate of bug 50947 ***",task_subcomment,"This is a duplicate of bug 50947 - merging. *** This bug has been marked as a duplicate of bug 50947 ***",ACTION ON ISSUE 240925,"VisualEditor - Using ""Select all"" (Ctrl+a) and deleting the selected content afterwards leaves the document uneditable.","On Firefox I can get pawns too, or keypresses causing the character to appear twice, if I do 1. Control-A 2. Delete 3. type 'a' But the page becomes unusable if I follow these steps: 1. Control-A 2. Delete 3. Click on the link icon, or anything else 4. type a- doesnt work",task_subcomment,"On Firefox I can get pawns too, or keypresses causing the character to appear twice, if I do 1. Control-A 2. Delete 3. type 'a' But the page becomes unusable if I follow these steps: 1. Control-A 2. Delete 3. Click on the link icon, or anything else 4. type a- doesnt work",BUG REPRODUCTION 240917,"VisualEditor - Using ""Select all"" (Ctrl+a) and deleting the selected content afterwards leaves the document uneditable.","Slight alteration: Chrome 28 does seem to be affected after all, though the problem is less severe. (Chrome) - Open the [[Nodeulseom]] in the visual editor. - Press CTRL+A to select everything on the page. - Press Delete. Chrome will place a pawn (♙) in the article as soon as one starts typing after the deletion. Often this pawn is also a hyperlink. Firefox will behave in a similar fashion on this specific page. Both Chrome and Firefox report a single error in the console: ""Error: Offset could not be translated to a DOM element and offset: 3"" This is probably because the article in this instance isn't blanked entirely. Ctrl+a followed by delete doesn't seem to delete the categories present in the article.",task_subcomment,"Slight alteration: Chrome 28 does seem to be affected after all, though the problem is less severe. (Chrome) - Open the [[Nodeulseom]] in the visual editor. - Press CTRL+A to select everything on the page. - Press Delete. Chrome will place a pawn (♙) in the article as soon as one starts typing after the deletion. Often this pawn is also a hyperlink. Firefox will behave in a similar fashion on this specific page. Both Chrome and Firefox report a single error in the console: ""Error: Offset could not be translated to a DOM element and offset: 3"" This is probably because the article in this instance isn't blanked entirely. Ctrl+a followed by delete doesn't seem to delete the categories present in the article.",BUG REPRODUCTION 54124,VisualEditor or Parsoid: Breaks and partially duplicates html tag,"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
    was duplicated minus the leading < Possibly related to bug 51304? -------------------------- **Version**: unspecified **Severity**: normal",task_description,"en.wp editor DragonsFlight reports a strange diff at URL where a
    was duplicated minus the leading < Possibly related to bug 51304? -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 240895,VisualEditor or Parsoid: Breaks and partially duplicates html tag,"Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",task_subcomment,"Can't reproduce; probably a transient Parsoid DSR and off-by-one error, given the issue. Marking as ""WORKSFORME"", but please re-open if it recurs or further information is available.",BUG REPRODUCTION 240890,VisualEditor or Parsoid: Breaks and partially duplicates html tag,"Given the proximity of the image, im guessing this is bug 52107.",task_subcomment,"Given the proximity of the image, im guessing this is bug 52107.",BUG REPRODUCTION 54116,VisualEditor - EditIntro is incorrectly linked in the monobook skin.,"(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",task_description,"(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: URL -- The ""Edit Source"" link will be: URL (Monobook - Working incorrectly) - Navigate to [[Martin J. Silverstein]]. -- The ""Edit"" link will be: URL -- The ""Edit Source"" link will be: URL 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",BUG REPRODUCTION 240385,VisualEditor - EditIntro is incorrectly linked in the monobook skin.,"Marking as INVALID, as per standard practice for issues with on-wiki code. (Has this been fixed?)",task_subcomment,"Marking as INVALID, as per standard practice for issues with on-wiki code. (Has this been fixed?)",ISSUE CONTENT MANAGEMENT 240378,VisualEditor - EditIntro is incorrectly linked in the monobook skin.,Confirming problem exists. The fix probably needs to be made at [[MediaWiki:Common.js]],task_subcomment,Confirming problem exists. The fix probably needs to be made at [[MediaWiki:Common.js]],BUG REPRODUCTION 54107,VisualEditor: image followed immediately with wikilink causes dirty diff,"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",task_description,"See URL and URL Reproduced at URL URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 239940,VisualEditor: image followed immediately with wikilink causes dirty diff,"Sorry for getting to this bug so late. I can't reproduce this bug at all. However, I have a number of confusions and questions about the bug report such that I don't know if that's because the bug has been fixed, was never present, or I just can't understand it… :-( ""In VE, the image is not editable."" What does ""not editable"" mean? You can't move? Can't resize? Can't add a caption? Can't delete? Doesn't appear? ""(note the diff is a mess)"" Is it? What kind of mess? Details help a lot in a complex system so we can tell whether we can reproduce or not. Is the VE still the same VE that you had open in step 2 (with the changes made to the text line into ""abc def gh"", and the WT changes made in step 3 also made but in parallel to the edit)? See https://www.mediawiki.org/wiki/VisualEditor:Bug_52107 for my testing page. Am provisionally marking this as ""WORKSFORME"", which is very unsatisfactory. :-( Happy to review if we can have further information.",task_subcomment,"Sorry for getting to this bug so late. I can't reproduce this bug at all. However, I have a number of confusions and questions about the bug report such that I don't know if that's because the bug has been fixed, was never present, or I just can't understand it… :-( ""In VE, the image is not editable."" What does ""not editable"" mean? You can't move? Can't resize? Can't add a caption? Can't delete? Doesn't appear? ""(note the diff is a mess)"" Is it? What kind of mess? Details help a lot in a complex system so we can tell whether we can reproduce or not. Is the VE still the same VE that you had open in step 2 (with the changes made to the text line into ""abc def gh"", and the WT changes made in step 3 also made but in parallel to the edit)? See URL for my testing page. Am provisionally marking this as ""WORKSFORME"", which is very unsatisfactory. :-( Happy to review if we can have further information.",BUG REPRODUCTION 239930,VisualEditor: image followed immediately with wikilink causes dirty diff,"Here is another case that looks similar: https://en.wikipedia.org/w/index.php?title=Persian_language&diff=prev&oldid=566108307",task_subcomment,"Here is another case that looks similar: URL",BUG REPRODUCTION 239921,VisualEditor: image followed immediately with wikilink causes dirty diff,"Steps to reproduce: 1. Create a page with "" abc def gh [[File:Andrew-W.K.-The-Party-All-Goddamn-Night-EP-2011.jpg|thumb|right]][[Sambanthar|Thirugnana Sambanthar]] of the [[Shaiva Siddhanta]] school. "" 2. In VE, the image is not editable. Place the cursor at 'c', press space and then delete: converting the first line to ""abc def gh"" - press save, review changes. (note that the diff looks good. Do not save.) 3. In Source Editor, after gh add ' ij' and save 4. In VE, repeat step 2 (note the diff is a mess) Confirmed any image does this; and tested in Chrome and Firefox.",task_subcomment,"Steps to reproduce: 1. Create a page with "" abc def gh [[File:Andrew-W.K.-The-Party-All-Goddamn-Night-EP-2011.jpg|thumb|right]][[Sambanthar|Thirugnana Sambanthar]] of the [[Shaiva Siddhanta]] school. "" 2. In VE, the image is not editable. Place the cursor at 'c', press space and then delete: converting the first line to ""abc def gh"" - press save, review changes. (note that the diff looks good. Do not save.) 3. In Source Editor, after gh add ' ij' and save 4. In VE, repeat step 2 (note the diff is a mess) Confirmed any image does this; and tested in Chrome and Firefox.",BUG REPRODUCTION 239917,VisualEditor: image followed immediately with wikilink causes dirty diff,"This looks like a string buffer problem, as it inserts different pieces of text into the same spot. And it appears to only happen every second edit. https://en.wikipedia.org/w/index.php?title=User:John_Vandenberg/test&action=history&offset=20130727021955&limit=4 The testcase is fairly small now https://en.wikipedia.org/wiki/User:John_Vandenberg/test My process for reproducing the bug is to open the page in VE, merge the first two paragraphs (i.e. bring 'other Hindu views' up to the 'and'). Review. If that doesnt trigger it, edit source, remove a word further down in the page, save, and remove the process in VE.",task_subcomment,"This looks like a string buffer problem, as it inserts different pieces of text into the same spot. And it appears to only happen every second edit. URL The testcase is fairly small now URL My process for reproducing the bug is to open the page in VE, merge the first two paragraphs (i.e. bring 'other Hindu views' up to the 'and'). Review. If that doesnt trigger it, edit source, remove a word further down in the page, save, and remove the process in VE.",BUG REPRODUCTION 54103,Missing nowiki escaping when single quotes wrap new i/b tags,"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/foo<\/i>/g;"" | node parse --html2wt [[Foo|'''foo''']] [subbu@earth lib] echo ""[[Foo|'foo']]"" | node parse | sed ""s/foo/foo<\/b>/g;"" | node parse --html2wt [[Foo|''''foo'''']] -------------------------- **Version**: unspecified **Severity**: normal",task_description,"Reported at: URL Simplified test cases here: [subbu@earth lib] echo ""[[Foo|'foo']]"" | node parse | sed ""s/foo/foo<\/i>/g;"" | node parse --html2wt [[Foo|'''foo''']] [subbu@earth lib] echo ""[[Foo|'foo']]"" | node parse | sed ""s/foo/foo<\/b>/g;"" | node parse --html2wt [[Foo|''''foo'''']] -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 239734,Missing nowiki escaping when single quotes wrap new i/b tags,Deployed and tested in production.,task_subcomment,Deployed and tested in production.,TASK PROGRESS 239730,Missing nowiki escaping when single quotes wrap new i/b tags,"Change 76467 merged by jenkins-bot: Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags https://gerrit.wikimedia.org/r/76467",task_subcomment,"Change 76467 merged by jenkins-bot: Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags GERRIT_URL",TASK PROGRESS 239726,Missing nowiki escaping when single quotes wrap new i/b tags,"Change 76467 had a related patch set uploaded by Subramanya Sastry: Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags https://gerrit.wikimedia.org/r/76467",task_subcomment,"Change 76467 had a related patch set uploaded by Subramanya Sastry: Take #2: (Bug 52103) nowiki escaping when quotes surround i/b tags GERRIT_URL",ACTION ON ISSUE 239719,Missing nowiki escaping when single quotes wrap new i/b tags,"Change 76162 merged by jenkins-bot: (Bug 52103) escape when single quotes wrap new i/b tags https://gerrit.wikimedia.org/r/76162",task_subcomment,"Change 76162 merged by jenkins-bot: (Bug 52103) escape when single quotes wrap new i/b tags GERRIT_URL",ACTION ON ISSUE 239713,Missing nowiki escaping when single quotes wrap new i/b tags,"Change 76162 had a related patch set uploaded by Subramanya Sastry: (Bug 52103) escape when single quotes wrap new i/b tags https://gerrit.wikimedia.org/r/76162",task_subcomment,"Change 76162 had a related patch set uploaded by Subramanya Sastry: (Bug 52103) escape when single quotes wrap new i/b tags GERRIT_URL",ACTION ON ISSUE 54086,User preference to disable VisualEditor (VE product),"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",task_description,"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 URL 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 URL ). -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: URL",FUTURE PLAN 238867,User preference to disable VisualEditor (VE product),"I am a bit disappointed by this closing, although it was only a suggestion of generalisation of the Wikimedia configuration for progressive deployment on third-party wikis. But it’s not very important.",task_subcomment,"I am a bit disappointed by this closing, although it was only a suggestion of generalisation of the Wikimedia configuration for progressive deployment on third-party wikis. But it’s not very important.",SOLUTION USAGE 238859,User preference to disable VisualEditor (VE product),"On-wiki configuration management is a much bigger piece than just for VisualEditor; I think it's probably marking this as WONTFIX within the context of VE, but instead suggest that the RfCs for this (as a piecemeal approach seems worse than nothing).",task_subcomment,"On-wiki configuration management is a much bigger piece than just for VisualEditor; I think it's probably marking this as WONTFIX within the context of VE, but instead suggest that the RfCs for this (as a piecemeal approach seems worse than nothing).",SOLUTION USAGE 238853,User preference to disable VisualEditor (VE product),"(In reply to comment #0) ... > 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 ). About this, see also bug 52188.",task_subcomment,"(In reply to comment #0) ... QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE About this, see also bug 52188.",ACTION ON ISSUE 238849,User preference to disable VisualEditor (VE product),"In the proposed scenario the default values of the two preferences visualeditor-enable and visualeditor-disable would be false: in a beta environment the default is ""not enabled by default=false"", and in the production environment the default is ""not disabled by default=false"".",task_subcomment,"In the proposed scenario the default values of the two preferences visualeditor-enable and visualeditor-disable would be false: in a beta environment the default is ""not enabled by default=false"", and in the production environment the default is ""not disabled by default=false"".",SOLUTION DISCUSSION 54083,VisualEditor: References that are added by templates are not recognized by the references tool,"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 tag, but about template that add the 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 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",task_description,"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 tag, but about template that add the 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 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",BUG REPRODUCTION 238669,VisualEditor: References that are added by templates are not recognized by the references tool,"The problems with references created by templates are numerous, and possibly impossible to fix ({{#tag:ref}} was never meant to work and this is an example of it not working). :-( In general they are part of bug 50474, but I'll expand that to be clearer. *** This bug has been marked as a duplicate of bug 50474 ***",task_subcomment,"The problems with references created by templates are numerous, and possibly impossible to fix ({{#tag:ref}} was never meant to work and this is an example of it not working). :-( In general they are part of bug 50474, but I'll expand that to be clearer. *** This bug has been marked as a duplicate of bug 50474 ***",MOTIVATION 54080,"Wrong tab-order on the ""Edit summary"" window","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 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",task_description,"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 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"". URL tab-order on the ""Edit summary"" window -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION DISCUSSION 238544,"Wrong tab-order on the ""Edit summary"" window"," *** This bug has been marked as a duplicate of bug 51918 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 51918 ***",ACTION ON ISSUE 238536,"Wrong tab-order on the ""Edit summary"" window"," *** This bug has been marked as a duplicate of bug 50047 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50047 ***",ACTION ON ISSUE 54044,VisualEditor: only a part of word is linked and is added,"When I select text that ends in the middle of the word and add a link, only the selected part is linked. Also, 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",task_description,"When I select text that ends in the middle of the word and add a link, only the selected part is linked. Also, is added after the link. For example, in URL 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",BUG REPRODUCTION 235865,VisualEditor: only a part of word is linked and is added,"This is not a 'bug', but intentional behaviour. If you actually want to produce [[Foo]]ian as opposed to [[Foo|Fooian]], VisualEditor/Parsoid doesn't have a way to guarantee that (right now Parsoid creates piped links even when it could do link trails/heads, but this could change in the future), because it's irrelevant to the reader and to editors. Consequently I'm marking this as ""WONTFIX"", but see bug 37939 for a wider discussion of the usability issue.",task_subcomment,"This is not a 'bug', but intentional behaviour. If you actually want to produce [[Foo]]ian as opposed to [[Foo|Fooian]], VisualEditor/Parsoid doesn't have a way to guarantee that (right now Parsoid creates piped links even when it could do link trails/heads, but this could change in the future), because it's irrelevant to the reader and to editors. Consequently I'm marking this as ""WONTFIX"", but see bug 37939 for a wider discussion of the usability issue.",ACTION ON ISSUE 54036,VisualEditor: blanking a page doesn't remove comments,"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",task_description,"See URL which, blanked, turns into URL 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**: URL",WORKAROUNDS 235456,VisualEditor: blanking a page doesn't remove comments," *** This bug has been marked as a duplicate of bug 49603 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 49603 ***",ACTION ON ISSUE 235450,VisualEditor: blanking a page doesn't remove comments,"Providing new link since that user's sandbox is gone: https://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox_VE&diff=63959567&oldid=63959556 .",task_subcomment,"Providing new link since that user's sandbox is gone: URL .",ACTION ON ISSUE 54032,VisualEditor: No easy way to add content before a template at the start of a line,"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",task_description,"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. URL ) 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**: URL",BUG REPRODUCTION 235138,VisualEditor: No easy way to add content before a template at the start of a line,"This is caused by bug 49784; if we knew that the template you'd just added was a block, we would insert a slug above the template (which exists precisely for this reason). Merging. *** This bug has been marked as a duplicate of bug 49784 ***",task_subcomment,"This is caused by bug 49784; if we knew that the template you'd just added was a block, we would insert a slug above the template (which exists precisely for this reason). Merging. *** This bug has been marked as a duplicate of bug 49784 ***",ACTION ON ISSUE 235130,VisualEditor: No easy way to add content before a template at the start of a line,"Whatamidoing comments that the issue is that there is no way easy to select a line starting with a template: So someone added a book to a ==Further reading== section. Book #1 used a citation template. Book #2 did not. Neither had bullet list formatting. Selecting them was hard. I ended up selecting the header, the template, and the plain-text citation. Then I clicked the 'list' button. Then I went back and repaired the formatting for the section heading. This isn't necessary, but it was easier than trying to figure out the exact stop to place the cursor. [...] [The] problem is that it's hard to select just the line that contains the template. You have to find the magic spot in the middle of ""==Heading=={{template}}"" to select the template without picking up the entire section heading. I managed it later in testing, but only if I'm selecting text with arrow keys. With the trackpad, it's still beyond me.",task_subcomment,"Whatamidoing comments that the issue is that there is no way easy to select a line starting with a template: So someone added a book to a ==Further reading== section. Book #1 used a citation template. Book #2 did not. Neither had bullet list formatting. Selecting them was hard. I ended up selecting the header, the template, and the plain-text citation. Then I clicked the 'list' button. Then I went back and repaired the formatting for the section heading. This isn't necessary, but it was easier than trying to figure out the exact stop to place the cursor. [...] [The] problem is that it's hard to select just the line that contains the template. You have to find the magic spot in the middle of ""==Heading=={{template}}"" to select the template without picking up the entire section heading. I managed it later in testing, but only if I'm selecting text with arrow keys. With the trackpad, it's still beyond me.",SOLUTION DISCUSSION 54028,TemplateData should allow specifying default values for parameters,"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",task_description,"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",SOLUTION DISCUSSION 234901,TemplateData should allow specifying default values for parameters," *** This bug has been marked as a duplicate of bug 51428 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 51428 ***",ACTION ON ISSUE 53998,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","**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}",task_description,"**Author:** CODE **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, URL the result page URL 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}",BUG REPRODUCTION 232237,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","**lovefilms** wrote: I am in FF23.0.1 and the VisualEditor is working as intended now. I go ahead to mark it as Resolved - since people can always use the new version of FF.",task_subcomment,"**lovefilms** wrote: I am in FF23.0.1 and the VisualEditor is working as intended now. I go ahead to mark it as Resolved - since people can always use the new version of FF.",SOLUTION USAGE 232234,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","Firefox 23.0 for Ubuntu: Everything works fine when clicking the ""Edit (beta)"" link at https://en.wikipedia.org/wiki/Blue_Jasmine#Production - fullscreen window as well as small window. Chromium 28.0.1500.71 for Ubuntu Same thing a above. It just works.",task_subcomment,"Firefox 23.0 for Ubuntu: Everything works fine when clicking the ""Edit (beta)"" link at URL - fullscreen window as well as small window. Chromium 28.0.1500.71 for Ubuntu Same thing a above. It just works.",BUG REPRODUCTION 232230,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","**lovefilms** wrote: I am using Firefox 22 as well (on Windows 7). The IE9 doesn't seem to have the VisualEditor, the edit link will simply goes to https://en.wikipedia.org/w/index.php?title=Blue_Jasmine&action=edit§ion=3",task_subcomment,"**lovefilms** wrote: I am using Firefox 22 as well (on Windows 7). The IE9 doesn't seem to have the VisualEditor, the edit link will simply goes to URL",BUG REPRODUCTION 232225,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","(e/c) I can reproduce on Firefox 22/Linux and Windows, and on Chrome/Windows to a lesser degree when using https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit#Production or when loading https://en.wikipedia.org/wiki/Blue_Jasmine?veaction=edit and click the 'edit' link beside 'Production' (the bug doesnt occur if middle-clicked, as that open the url with 'vesection=3' added). Most times I do this, it is possible to see the viewport position itself correctly at the anchor, but then then toolbar appears covering the section heading and a half of the first line of text.",task_subcomment,"(e/c) I can reproduce on Firefox 22/Linux and Windows, and on Chrome/Windows to a lesser degree when using URL or when loading URL and click the 'edit' link beside 'Production' (the bug doesnt occur if middle-clicked, as that open the url with 'vesection=3' added). Most times I do this, it is possible to see the viewport position itself correctly at the anchor, but then then toolbar appears covering the section heading and a half of the first line of text.",BUG REPRODUCTION 232218,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","I think is is related to screen resolution \ the size of the browser window. If you have a low resolution (Or resize the browser window to be small enough) Firefox 22 and Chrome 28 will place the ""ve-ui-toolbar-actions"" element on a second line in the edit toolbar. If you edit a section in the small-size browser it will scroll to the section as it normally would, but doesn't take the twice-as-high-as-usual edit toolbar into account when determining where to stop. As a result the section header is actually positioned under the second toolbar line. If you resize the browser afterwards to a size that allows for a single-line edit toolbar the section header will be correctly positioned.",task_subcomment,"I think is is related to screen resolution \ the size of the browser window. If you have a low resolution (Or resize the browser window to be small enough) Firefox 22 and Chrome 28 will place the ""ve-ui-toolbar-actions"" element on a second line in the edit toolbar. If you edit a section in the small-size browser it will scroll to the section as it normally would, but doesn't take the twice-as-high-as-usual edit toolbar into account when determining where to stop. As a result the section header is actually positioned under the second toolbar line. If you resize the browser afterwards to a size that allows for a single-line edit toolbar the section header will be correctly positioned.",BUG REPRODUCTION 232210,"When use Firefox to edit a section of an article, the VisualEditor ends up incorrect position","Which Firefox version is this about? Can you reproduce the problem with other browsers?",task_subcomment,"Which Firefox version is this about? Can you reproduce the problem with other browsers?",BUG REPRODUCTION 53989,"VisualEditor: ""add template"" should have the same functionality as return in the template dialog","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",task_description,"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",BUG REPRODUCTION 255208,"VisualEditor: ""add template"" should have the same functionality as return in the template dialog",This was done some time ago as part of the tweaks to the input box.,task_subcomment,This was done some time ago as part of the tweaks to the input box.,SOLUTION DISCUSSION 53976,"Impossible to edit a specific section when switching from VisualEditor to ""legacy mode"" (due to reference to QuickEdit gadget in vector.js?)","**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",task_description,"**Author:** CODE **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",BUG REPRODUCTION 254477,"Impossible to edit a specific section when switching from VisualEditor to ""legacy mode"" (due to reference to QuickEdit gadget in vector.js?)","**l736ewiki** wrote: I'm using vector. The issue appeared both on Safari/OS X (Mountain Lion, 10.8) and on Firefox/Windows XP Pro. However, I was apparently able to overcome the issue. I read in the FAQ that it's recommended to disable the QuickEdit extension to avoid undesired effects with VE, so I checked in my preference pane that this extension was actually disabled (and it was). However, in my vector.js fiel, inside the ""toLoad"" variable, there was a reference to QuickEdit gadget (qed). Looks like the presence of that string inside vector.js actually caused the extension to be loaded anyway. Removing that string from the vector.js and refreshing the browser's cache overcame the issue. Now I'm able to open VE directly over single individual sections. So the results are: * it's not enough to verify in the preference pane that the QuickEdit extension is disabled * any reference to QuickEdit shall be removed also from the local vector.js (or monobook.js, I assume then)",task_subcomment,"**l736ewiki** wrote: I'm using vector. The issue appeared both on Safari/OS X (Mountain Lion, 10.8) and on Firefox/Windows XP Pro. However, I was apparently able to overcome the issue. I read in the FAQ that it's recommended to disable the QuickEdit extension to avoid undesired effects with VE, so I checked in my preference pane that this extension was actually disabled (and it was). However, in my vector.js fiel, inside the ""toLoad"" variable, there was a reference to QuickEdit gadget (qed). Looks like the presence of that string inside vector.js actually caused the extension to be loaded anyway. Removing that string from the vector.js and refreshing the browser's cache overcame the issue. Now I'm able to open VE directly over single individual sections. So the results are: * it's not enough to verify in the preference pane that the QuickEdit extension is disabled * any reference to QuickEdit shall be removed also from the local vector.js (or monobook.js, I assume then)",BUG REPRODUCTION 254470,"Impossible to edit a specific section when switching from VisualEditor to ""legacy mode"" (due to reference to QuickEdit gadget in vector.js?)","I can't reproduce this on it.wiki, using vector skin and Firefox/Linux. Does this happen on every article for you? Which skin are you using?",task_subcomment,"I can't reproduce this on it.wiki, using vector skin and Firefox/Linux. Does this happen on every article for you? Which skin are you using?",BUG REPRODUCTION 53968,VisualEditor: can't remove missing image,"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",task_description,"URL If you tried to edit with VE, the missing image link would just disappear. Thanks. -------------------------- **Version**: unspecified **Severity**: normal",SOLUTION USAGE 254194,VisualEditor: can't remove missing image," *** This bug has been marked as a duplicate of bug 50788 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 50788 ***",ACTION ON ISSUE 254188,VisualEditor: can't remove missing image,"Confirming. To make the description more clear: even if in view mode you can see the name in red of the missing image and the caption, with VisualEditor you won't see a thing, and therefore it's impossible to edit or delete the image object. There is a test page at http://test2.wikipedia.org/wiki/MissingImageVEtest I found about this while trying to remove the captions in an article of two images that had been deleted at Commons: http://ca.wikipedia.org/w/index.php?title=Remedios_Varo&oldid=11208969 The only way to do this is editing source the old way.",task_subcomment,"Confirming. To make the description more clear: even if in view mode you can see the name in red of the missing image and the caption, with VisualEditor you won't see a thing, and therefore it's impossible to edit or delete the image object. There is a test page at URL I found about this while trying to remove the captions in an article of two images that had been deleted at Commons: URL The only way to do this is editing source the old way.",BUG REPRODUCTION 254183,VisualEditor: can't remove missing image,I actually moved the above comment to https://bugzilla.wikimedia.org/show_bug.cgi?id=52575 . Thanks.,task_subcomment,I actually moved the above comment to URL . Thanks.,ACTION ON ISSUE 254178,VisualEditor: can't remove missing image,http://en.wikipedia.org/w/index.php?title=Walton_%28company%29&diff=567155604&oldid=565055473 This might be related (not sure how they managed to remove the bracket!),task_subcomment,URL This might be related (not sure how they managed to remove the bracket!),SOLUTION USAGE 254171,VisualEditor: can't remove missing image,"It disappears in VE for me too. 1. modify the page (add a ' ' anywhere) 2. 'Save page' and 'review your changes' The diff 'inserts' [[File:Pieve San Giovanni.jpg|thumb|200px|San Giovanni Battista]]",task_subcomment,"It disappears in VE for me too. 1. modify the page (add a ' ' anywhere) 2. 'Save page' and 'review your changes' The diff 'inserts' [[File:Pieve San Giovanni.jpg|thumb|200px|San Giovanni Battista]]",BUG REPRODUCTION 53959,VisualEditor or Parsoid tried to convert slash-separate numbers into and refused to save,"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 :...in common with the Classes 313 / 314 / 315 / 507 / 508 units. 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",task_description,"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 :...in common with the Classes 313 / 314 / 315 / 507 / 508 units. 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**: URL",BUG REPRODUCTION 253777,VisualEditor or Parsoid tried to convert slash-separate numbers into and refused to save,This might be default behavior in the Safari iOS contenteditable. In that case we probably need to file a bugreport upstream.,task_subcomment,This might be default behavior in the Safari iOS contenteditable. In that case we probably need to file a bugreport upstream.,BUG REPRODUCTION 253771,VisualEditor or Parsoid tried to convert slash-separate numbers into and refused to save,"Just for reference, the original reporter subsequently noted that they use Ipad IOS6 with Safari",task_subcomment,"Just for reference, the original reporter subsequently noted that they use Ipad IOS6 with Safari",ACTION ON ISSUE 253763,VisualEditor or Parsoid tried to convert slash-separate numbers into and refused to save,"This is almost certainly due to a browser plugin that thinks it's being ""helpful"". Certainly, nothing in VisualEditor or Parsoid understand href=tel: links, so it's not going to come from us. I also can't reproduce locally in Firefox, Safari or Chrome. Marking as INVALID (but we are seeing a small number of these consistent due to people having broken plugins; we're investigating whether there's a way to stop them).",task_subcomment,"This is almost certainly due to a browser plugin that thinks it's being ""helpful"". Certainly, nothing in VisualEditor or Parsoid understand href=tel: links, so it's not going to come from us. I also can't reproduce locally in Firefox, Safari or Chrome. Marking as INVALID (but we are seeing a small number of these consistent due to people having broken plugins; we're investigating whether there's a way to stop them).",BUG REPRODUCTION 253753,VisualEditor or Parsoid tried to convert slash-separate numbers into and refused to save,This may be a VE issue if you are seeing a-href showing up in wikitext on serialization.,task_subcomment,This may be a VE issue if you are seeing a-href showing up in wikitext on serialization.,BUG REPRODUCTION 53950,VisualEditor: tags not deleted when surrounding element or text is deleted,"User Atethnekos at en.wp reports: ""If in the source code there is <blockquote>, and in VE I select ""
    "" and delete it, when I save the 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",task_description,"User Atethnekos at en.wp reports: ""If in the source code there is <blockquote>, and in VE I select ""
    "" and delete it, when I save the is left behind in the source code."" See URL for an example in by sandbox. Further testing shows that it also happens with other tags and even with plain text: URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 253282,VisualEditor: tags not deleted when surrounding element or text is deleted,"This is the same as bug 47678, which now fixed in some code we created this week, but unfortunately that has an issue, bug 51948 which is preventing wider deployment. Hopefully we'll get that fixed next week. *** This bug has been marked as a duplicate of bug 47678 ***",task_subcomment,"This is the same as bug 47678, which now fixed in some code we created this week, but unfortunately that has an issue, bug 51948 which is preventing wider deployment. Hopefully we'll get that fixed next week. *** This bug has been marked as a duplicate of bug 47678 ***",BUG REPRODUCTION 53938,VisualEditor: Deleting last use of reference should remove the entry from ..,"This is related to Bug 51741, which is about adding support for ... If the page already has .., and the last use of a named reference is removed, the entry inside .. 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: tag with name ""rockspot_1"" defined in is not used in prior text."" -------------------------- **Version**: unspecified **Severity**: normal",task_description,"This is related to Bug 51741, which is about adding support for ... If the page already has .., and the last use of a named reference is removed, the entry inside .. needs to be removed otherwise an error is generated after save. Steps to reproduce: 1. URL 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: tag with name ""rockspot_1"" defined in is not used in prior text."" -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 252743,VisualEditor: Deleting last use of reference should remove the entry from ..,This was done some time ago; sorry for the slow triage.,task_subcomment,This was done some time ago; sorry for the slow triage.,ACTION ON ISSUE 53925,VisualEditor: Retain newlines between parameters in transclusion invocations,"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",task_description,"Steps to reproduce: 1. URL 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 URL Regarding the actual bug, I saw a similar diff ~20 hrs ago: URL -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 251794,VisualEditor: Retain newlines between parameters in transclusion invocations,This was fixed some time ago; sorry for the slow triage.,task_subcomment,This was fixed some time ago; sorry for the slow triage.,ACTION ON ISSUE 251786,VisualEditor: Retain newlines between parameters in transclusion invocations,"And another one reported on en:VEF in case it helps https://en.wikipedia.org/w/index.php?title=Rebel_Beat_%28Goo_Goo_Dolls_song%29&diff=566058910&oldid=565340967",task_subcomment,"And another one reported on en:VEF in case it helps URL",SOLUTION DISCUSSION 53907,VisualEditor: DEFAULTSORT suggestions should use/not use diacritics on based on wiki policy,"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",task_description,"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",SOLUTION USAGE 250417,VisualEditor: DEFAULTSORT suggestions should use/not use diacritics on based on wiki policy,"VisualEditor is not ""suggesting"" a default page sort - the placeholder text informs the user what the page is currently sorted as (i.e., the page's name). Marking as INVALID.",task_subcomment,"VisualEditor is not ""suggesting"" a default page sort - the placeholder text informs the user what the page is currently sorted as (i.e., the page's name). Marking as INVALID.",ACTION ON ISSUE 53905,VisualEditor: Inserting media dialog has no confirmation button,"**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}",task_description,"**Author:** CODE **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}",BUG REPRODUCTION 250356,VisualEditor: Inserting media dialog has no confirmation button,Closing this as no confirmation of report as written. Bug 51911 gets the gist of the issue.,task_subcomment,Closing this as no confirmation of report as written. Bug 51911 gets the gist of the issue.,ACTION ON ISSUE 250351,VisualEditor: Inserting media dialog has no confirmation button,Sorry for confirming; the UI design should be a separate bug.,task_subcomment,Sorry for confirming; the UI design should be a separate bug.,SOLUTION DISCUSSION 250345,VisualEditor: Inserting media dialog has no confirmation button,"It does look very bare, and many users will be thinking ""do I need to double click""? (we have MS to thank for that) I would prefer to select an image, be prompted for a caption (an overlay appears), and then apply changes. That would partially solve bug 51911, as the user would feel more confident that they had inserted the image, and they would go looking for it.",task_subcomment,"It does look very bare, and many users will be thinking ""do I need to double click""? (we have MS to thank for that) I would prefer to select an image, be prompted for a caption (an overlay appears), and then apply changes. That would partially solve bug 51911, as the user would feel more confident that they had inserted the image, and they would go looking for it.",SOLUTION DISCUSSION 250339,VisualEditor: Inserting media dialog has no confirmation button,Bug/enhancement reported as bug 51911.,task_subcomment,Bug/enhancement reported as bug 51911.,BUG REPORT 250334,VisualEditor: Inserting media dialog has no confirmation button,"Maybe you are inserting the image somewhere out of your field of view? For example if there is an infobox in the article, or many pictures aligned to the right, the image you are inserting may be inserted BELOW all this, where you cannot see it. Regardless of whether this is the actual problem in this particular case, I think that it is a potential problem for others. I tried inserting an image in an article with an infobox, and indeed the image was inserted below it, out of my field of view. This could lead to puzzled users and even unintended bad edits, and I think that the solution is fairly simple: making the VisualEditor scroll the screen down to wherever the image is inserted. I'll report this to the VisualEditor team.",task_subcomment,"Maybe you are inserting the image somewhere out of your field of view? For example if there is an infobox in the article, or many pictures aligned to the right, the image you are inserting may be inserted BELOW all this, where you cannot see it. Regardless of whether this is the actual problem in this particular case, I think that it is a potential problem for others. I tried inserting an image in an article with an infobox, and indeed the image was inserted below it, out of my field of view. This could lead to puzzled users and even unintended bad edits, and I think that the solution is fairly simple: making the VisualEditor scroll the screen down to wherever the image is inserted. I'll report this to the VisualEditor team.",SOLUTION DISCUSSION 250328,VisualEditor: Inserting media dialog has no confirmation button,That button was removed on purpose. You should be able to insert an image by simply clicking on the image.,task_subcomment,That button was removed on purpose. You should be able to insert an image by simply clicking on the image.,SOLUTION USAGE 53880,VisualEditor: Dragging cursor through multi-part template responds unpredictably in Firefox,"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",task_description,"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",BUG REPRODUCTION 249074,VisualEditor: Dragging cursor through multi-part template responds unpredictably in Firefox,"AFAICT this is now fixed, I believe due to the changes in selection handling in Firefox. Sorry for the slow triage.",task_subcomment,"AFAICT this is now fixed, I believe due to the changes in selection handling in Firefox. Sorry for the slow triage.",BUG REPRODUCTION 53875,General non VE feedback goes to the VE feedback page.,"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",task_description,"I've noticed quite a few edits going to the VE feedback page URL 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",SOLUTION DISCUSSION 248668,General non VE feedback goes to the VE feedback page.,"Marking this as ""WORKSFORME"", though really we should consider the broader ramifications for us and think about adding a prominent help button for users who clearly want it.",task_subcomment,"Marking this as ""WORKSFORME"", though really we should consider the broader ramifications for us and think about adding a prominent help button for users who clearly want it.",WORKAROUNDS 248660,General non VE feedback goes to the VE feedback page.,"Presumably the solution is to provide a proper help link for users for general concerns, rather than burying it where they never see it?",task_subcomment,"Presumably the solution is to provide a proper help link for users for general concerns, rather than burying it where they never see it?",SOLUTION DISCUSSION 53858,Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs,"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",task_description,"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**: URL",FUTURE PLAN 247738,Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs,"Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",task_subcomment,"Yeah. It's not integrated with the normal Wikitech interface, but my understanding is it gets the job done (I haven't really used Labs-Vagrant, but I have a general understanding how it works).",SOLUTION USAGE 247732,Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs,Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the `labs-vagrant` command can be used to manipulate roles and run puppet.,task_subcomment,Does ::role::labs::vagrant satisfy this request? Applying it via the wikitech interface provisions the labs host with a copy of MediaWiki-Vagrant and then the CODE command can be used to manipulate roles and run puppet.,TASK PROGRESS 247727,Share VisualEditor and Parsoid puppet module between Vagrant and Wikimedia Labs,[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.],task_subcomment,[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.],ACTION ON ISSUE 53835,VisualEditor: Changing login status / losing session data during edit causes VE to break silently,"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",task_description,"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",BUG REPRODUCTION 246479,VisualEditor: Changing login status / losing session data during edit causes VE to break silently,This was fixed some while ago as part of the save dialog re-write; sorry for the slow triage.,task_subcomment,This was fixed some while ago as part of the save dialog re-write; sorry for the slow triage.,SOLUTION USAGE 53833,FlaggedRevs/PendingChanges notices not appearing at pl.wikipedia.org,"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",task_description,"From URL 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",BUG REPRODUCTION 246378,FlaggedRevs/PendingChanges notices not appearing at pl.wikipedia.org,"Yeah, this isn't good; we've actually just-about fixed it and will deploy it the morning (San Francisco time). *** This bug has been marked as a duplicate of bug 49699 ***",task_subcomment,"Yeah, this isn't good; we've actually just-about fixed it and will deploy it the morning (San Francisco time). *** This bug has been marked as a duplicate of bug 49699 ***",ACTION ON ISSUE 246369,FlaggedRevs/PendingChanges notices not appearing at pl.wikipedia.org,"That's not the real issue. FlaggedRevs are enabled globally, for all pages, and *all non-autoreviewed edits require review before they are shown*; the only groups exempt from review are reviewers themselves and bots. (You can choose to view the so-called 'unstable' versions of pages instead of 'stable' ones in preferences.) Information about this is shown to viewers before, during and after editing (using the messages pointed out in the issue report WhatamIdoing linked) – but VE shows it in none of these contexts. I would consider this a blocker to deployment to anonymous users at least.",task_subcomment,"That's not the real issue. FlaggedRevs are enabled globally, for all pages, and *all non-autoreviewed edits require review before they are shown*; the only groups exempt from review are reviewers themselves and bots. (You can choose to view the so-called 'unstable' versions of pages instead of 'stable' ones in preferences.) Information about this is shown to viewers before, during and after editing (using the messages pointed out in the issue report WhatamIdoing linked) – but VE shows it in none of these contexts. I would consider this a blocker to deployment to anonymous users at least.",BUG REPRODUCTION 53831,Long lines in 
     blocks don't cause page formatting to extend right. The html page is extended massively further than needed,"Long 
     blocks rendered in Firefox 22 on Xubuntu Linux. Monobook skin.

When 
     blocks contain lines longer than the width of the page, the 
     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}",task_description,"Long 
     blocks rendered in Firefox 22 on Xubuntu Linux. Monobook skin.

When 
     blocks contain lines longer than the width of the page, the 
     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: URL

Firefox 22, Xubuntu Linux, Monobook skin.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11594}",BUG REPRODUCTION
246287,Long lines in 
     blocks don't cause page formatting to extend right. The html page is extended massively further than needed,"

*** This bug has been marked as a duplicate of bug 260 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 260 ***",ACTION ON ISSUE
246282,Long lines in 
     blocks don't cause page formatting to extend right. The html page is extended massively further than needed,"That really wouldn't surprise me, but I couldn't find anything when searching and nothing relevant popped up when I entered the summary. If it is a dupe then the other bug describes it using completely different words, probably describing the cause rather than the symptom.",task_subcomment,"That really wouldn't surprise me, but I couldn't find anything when searching and nothing relevant popped up when I entered the summary. If it is a dupe then the other bug describes it using completely different words, probably describing the cause rather than the symptom.",BUG REPRODUCTION
246276,Long lines in 
     blocks don't cause page formatting to extend right. The html page is extended massively further than needed,This is surely a dupe of something.,task_subcomment,This is surely a dupe of something.,POTENTIAL NEW ISSUES AND REQUESTS
53829,"Removing a heading is hard, leaving ==== or turning the next paragraph into a heading","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.

====

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",task_description,"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.

====

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",BUG REPRODUCTION
246183,"Removing a heading is hard, leaving ==== or turning the next paragraph into a heading","

*** This bug has been marked as a duplicate of bug 50100 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50100 ***",ACTION ON ISSUE
53827,VisualEditor: Tooltip shown when hovering over a link should also appear when link inspector icon is shown,"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",task_description,"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**:
URL",SOLUTION USAGE
246062,VisualEditor: Tooltip shown when hovering over a link should also appear when link inspector icon is shown,"WONTFIX. Display of tooltips is native behaviour, and though we *can* over-ride the browser and do it instead when we think we know better, we shouldn't (because we'll always miss something).",task_subcomment,"WONTFIX. Display of tooltips is native behaviour, and though we *can* over-ride the browser and do it instead when we think we know better, we shouldn't (because we'll always miss something).",ACTION ON ISSUE
53826,VisualEditor renderizes the image a lot bigger than it should,"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}",task_description,"Screenshot from [[pt:TV TEM]]

In the page
URL
the image is a lot bigger than it is on view mode
URL


This is a minimal example for the problem reported at
URL
which can be seen on this article:
URL
The screenshot provided was this:
URL

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL
**See Also**:
URL

**Attached**: {F11577}",BUG REPRODUCTION
246016,VisualEditor renderizes the image a lot bigger than it should,"

*** This bug has been marked as a duplicate of bug 51628 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 51628 ***",ACTION ON ISSUE
246010,VisualEditor renderizes the image a lot bigger than it should,"Parsoid keeps the code as is:
http://parsoid.wmflabs.org/_rt/pt/?oldid=36476193",task_subcomment,"Parsoid keeps the code as is:
URL",SOLUTION DISCUSSION
246005,VisualEditor renderizes the image a lot bigger than it should,"It seems to be caused by the extra ""px"" in the wikicode:
[[Image:Globo TV logo.svg|25pxpx]]",task_subcomment,"It seems to be caused by the extra ""px"" in the wikicode:
[[Image:Globo TV logo.svg|25pxpx]]",BUG REPRODUCTION
53820,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar","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",task_description,"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:
*URL

*URL

Original thread here:
URL

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL
URL",MOTIVATION
245692,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar","Thanks - as the editor who reported this bug in the first place. I didn't notice it had been fixed because AFAIK there was no report to say so, and I'm not using VE regularly until some other issues have been fixed to make it usable. (Glad to notice that there's some action on redlinks, but the dialog box hiding all article content is still the dealbreaker for me).",task_subcomment,"Thanks - as the editor who reported this bug in the first place. I didn't notice it had been fixed because AFAIK there was no report to say so, and I'm not using VE regularly until some other issues have been fixed to make it usable. (Glad to notice that there's some action on redlinks, but the dialog box hiding all article content is still the dealbreaker for me).",ACTION ON ISSUE
245689,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar",*** Bug 58933 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 58933 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
245688,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar",This was fixed by Trevor in January.,task_subcomment,This was fixed by Trevor in January.,SOLUTION USAGE
245686,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar","Though I spent a lot of time reporting these, both these are cases of the system behaving oddly rather than things which seriously affect editing. I reported them more in the sense of ""The system is doing these odd things which I'm telling you about in case it's symptomatic of something significant you should know about"" rather than ""Please fix them now"".

The first, that the title appears superimposed on the lower border of the editing toolbar area, is ugly, mildly disconcerting, and occurs at a very reasonable window width - I wasn't experimenting, just editing naturally this morning, when I found it happening. It's odd-looking, but does no serious harm.

The second, that the title only displays in a column much narrower than the width of the displayed text, and that long title words are truncated at a certain point, only occurs on quite narrow windows but looks very odd when it does happen. It's not going to seriously hamper anyone's editing.

I wouldn't like any effort to go into these bugs which could be used to address really important things like the {{Bug|49603}} on the invisibility of hidden comments and templates, or {{Bug|49969}} on dialog boxes hiding all article content: now those really do seriously affect editing.",task_subcomment,"Though I spent a lot of time reporting these, both these are cases of the system behaving oddly rather than things which seriously affect editing. I reported them more in the sense of ""The system is doing these odd things which I'm telling you about in case it's symptomatic of something significant you should know about"" rather than ""Please fix them now"".

The first, that the title appears superimposed on the lower border of the editing toolbar area, is ugly, mildly disconcerting, and occurs at a very reasonable window width - I wasn't experimenting, just editing naturally this morning, when I found it happening. It's odd-looking, but does no serious harm.

The second, that the title only displays in a column much narrower than the width of the displayed text, and that long title words are truncated at a certain point, only occurs on quite narrow windows but looks very odd when it does happen. It's not going to seriously hamper anyone's editing.

I wouldn't like any effort to go into these bugs which could be used to address really important things like the {{Bug|49603}} on the invisibility of hidden comments and templates, or {{Bug|49969}} on dialog boxes hiding all article content: now those really do seriously affect editing.",SOLUTION DISCUSSION
245683,"VisualEditor: When window is narrowed, article title can display over the top of the toolbar","Note I've been unable to reproduce this using Firefox 22 on Linux, so it might be OS-specific.",task_subcomment,"Note I've been unable to reproduce this using Firefox 22 on Linux, so it might be OS-specific.",BUG REPRODUCTION
53812,Transclusion editor: remove template creates blank dialog,"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",task_description,"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",BUG REPRODUCTION
245198,Transclusion editor: remove template creates blank dialog,"

*** This bug has been marked as a duplicate of bug 50281 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50281 ***",ACTION ON ISSUE
245193,Transclusion editor: remove template creates blank dialog,"Bug 50281 (which I think this duplicates) wins for mildly amusing title though - ""VisualEditor: Empty transclusion editor is empty, needs some kind of reassuring message""",task_subcomment,"Bug 50281 (which I think this duplicates) wins for mildly amusing title though - ""VisualEditor: Empty transclusion editor is empty, needs some kind of reassuring message""",SOCIAL CONVERSATION
245187,Transclusion editor: remove template creates blank dialog,"Creepy; I was about to submit this with the title ""VisualEditor: removing a template creates a blank dialog"" ;p.",task_subcomment,"Creepy; I was about to submit this with the title ""VisualEditor: removing a template creates a blank dialog"" ;p.",ACTION ON ISSUE
53806,"VisualEditor shows rowspan=""4"" on template generated tables","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}",task_description,"Screenshot of the table

See the link above and the attached screenshot.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL

**Attached**: {F11541}",BUG REPRODUCTION
244936,"VisualEditor shows rowspan=""4"" on template generated tables","Thanks for fixing the templates -- I will close this bug now without making any fixes in Parsoid.  While we could fix Parsoid to accommodate bugs in wikitext and templates (and there are several scenarios that we handle), for one-off scenarios, it is better to fix the templates/wikitext rather than clutter the Parsoid code base with exceptional conditions.  It is better in the long run and will enable maintenance of the code base.",task_subcomment,"Thanks for fixing the templates -- I will close this bug now without making any fixes in Parsoid.  While we could fix Parsoid to accommodate bugs in wikitext and templates (and there are several scenarios that we handle), for one-off scenarios, it is better to fix the templates/wikitext rather than clutter the Parsoid code base with exceptional conditions.  It is better in the long run and will enable maintenance of the code base.",SOLUTION USAGE
244933,"VisualEditor shows rowspan=""4"" on template generated tables","For now, I moved the relevant code from [[pt:Template:Tabfootrow]] to [[pt:Template:Tabfoot]] and then I updated the only two articles which uses that template and informed about this change in the talk page of one of them:
https://pt.wikipedia.org/wiki/Special:Contribs/Helder.wiki?dir=prev&offset=20130805170824&limit=11&uselang=en",task_subcomment,"For now, I moved the relevant code from [[pt:Template:Tabfootrow]] to [[pt:Template:Tabfoot]] and then I updated the only two articles which uses that template and informed about this change in the talk page of one of them:
URL",TASK PROGRESS
244932,"VisualEditor shows rowspan=""4"" on template generated tables","I left a message in the talk page of one of the articles which uses the template:
https://pt.wikipedia.org/wiki/Discuss%C3%A3o:Primeira_Liga_de_2013%E2%80%9314
and in the thread where its author announced the new template:
https://pt.wikipedia.org/wiki/WP:EA#Novas_predefini.C3.A7.C3.B5es_para_tabelas_de_futebol",task_subcomment,"I left a message in the talk page of one of the articles which uses the template:
URL
and in the thread where its author announced the new template:
URL",SOLUTION USAGE
244929,"VisualEditor shows rowspan=""4"" on template generated tables","I am not editing the template -- someone on pt wikipedia (matmarex) should verify that existing pages wont break with the change and do it.  But, offhand it does seem safe to fix.",task_subcomment,"I am not editing the template -- someone on pt wikipedia (matmarex) should verify that existing pages wont break with the change and do it.  But, offhand it does seem safe to fix.",TASK PROGRESS
244921,"VisualEditor shows rowspan=""4"" on template generated tables","Buggy template: http://pt.wikipedia.org/w/index.php?title=Predefini%C3%A7%C3%A3o:Tabfootrow&action=edit

It should be ""|rowspan=..."" instead of ""||rowspan=...""

echo ""{|\n|foo{{User:Ssastry/Templates/tabfootrow|rows=2|content=foobar}}\n|}"" | node parse

works properly with the correct wikitext.",task_subcomment,"Buggy template: URL

It should be ""|rowspan=..."" instead of ""||rowspan=...""

echo ""{|\n|foo{{User:Ssastry/Templates/tabfootrow|rows=2|content=foobar}}\n|}"" | node parse

works properly with the correct wikitext.",BUG REPRODUCTION
244915,"VisualEditor shows rowspan=""4"" on template generated tables",Parsoid bug: http://parsoid.wmflabs.org/pt/La_Liga_de_2006%E2%80%9307?oldid=36362539 (you'll have to scroll down quite a bit),task_subcomment,Parsoid bug: URL (you'll have to scroll down quite a bit),BUG REPRODUCTION
53805,VisualEditor: It's possible to edit pages that were translated using the Translate extension,"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",task_description,"The page URL 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",BUG REPRODUCTION
244865,VisualEditor: It's possible to edit pages that were translated using the Translate extension,"It's never actually been able to bypass the Translate extension's system-level protection of the page - but the problem is you shouldn't be able to trigger VE on the page in the first place, which is bug 50284.

*** This bug has been marked as a duplicate of bug 50284 ***",task_subcomment,"It's never actually been able to bypass the Translate extension's system-level protection of the page - but the problem is you shouldn't be able to trigger VE on the page in the first place, which is bug 50284.

*** This bug has been marked as a duplicate of bug 50284 ***",BUG REPRODUCTION
244857,VisualEditor: It's possible to edit pages that were translated using the Translate extension,"Urged by Niklas, I tried to save and got: ""Unsuccessful request: Unknown error: ""tpt-target-page"".""

So at least it doesn't ruin anything, but it should be more intuitive.",task_subcomment,"Urged by Niklas, I tried to save and got: ""Unsuccessful request: Unknown error: ""tpt-target-page"".""

So at least it doesn't ruin anything, but it should be more intuitive.",BUG REPRODUCTION
53793,VE: Page settings: Languages list cut off,"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}",task_description,"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}",BUG REPRODUCTION
244064,VE: Page settings: Languages list cut off,"Change 75083 abandoned by Rillke:
Adding important to overflow:auto on scrollable elements

Reason:
Fixed by If2d5ec3168a874eb4f856450583d6c89967513df

https://gerrit.wikimedia.org/r/75083",task_subcomment,"Change 75083 abandoned by Rillke:
Adding important to overflow:auto on scrollable elements

Reason:
Fixed by If2d5ec3168a874eb4f856450583d6c89967513df

GERRIT_URL",ACTION ON ISSUE
244059,VE: Page settings: Languages list cut off,"I'm pretty sure it's the same issue as on bug 51739.

*** This bug has been marked as a duplicate of bug 51739 ***",task_subcomment,"I'm pretty sure it's the same issue as on bug 51739.

*** This bug has been marked as a duplicate of bug 51739 ***",BUG REPRODUCTION
244055,VE: Page settings: Languages list cut off,"Change 75083 had a related patch set uploaded by Rillke:
Adding important to overflow:auto on scrollable elements

https://gerrit.wikimedia.org/r/75083",task_subcomment,"Change 75083 had a related patch set uploaded by Rillke:
Adding important to overflow:auto on scrollable elements

GERRIT_URL",ACTION ON ISSUE
53791,TemplateData for redirected templates,"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",task_description,"Many templates are redirects from a short name to a long name. An example is
URL which is a redirect to
URL and has 68742 pages transcluding it. Even though Commons_category has template data specified, and URL redirects to URL 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",BUG REPRODUCTION
243977,TemplateData for redirected templates,"

*** This bug has been marked as a duplicate of bug 50964 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50964 ***",ACTION ON ISSUE
243973,TemplateData for redirected templates,Discussed at http://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor/TemplateData#What_about_redirected_templates,task_subcomment,Discussed at URL,ACTION ON ISSUE
53771,VisualEditor: Search box and button intermittently appearing atop transclusion editor in Monobook skin,"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",task_description,"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:
URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
242861,VisualEditor: Search box and button intermittently appearing atop transclusion editor in Monobook skin,"This was caused by some issues with how the dialogs interacted with the Monobook skin, which have been subsequently fixed. Sorry for the slow triage.",task_subcomment,"This was caused by some issues with how the dialogs interacted with the Monobook skin, which have been subsequently fixed. Sorry for the slow triage.",BUG REPRODUCTION
53759,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'info' of undefined"" (when saving the page)","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",task_description,"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",BUG REPRODUCTION
242084,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'info' of undefined"" (when saving the page)","No reproduction steps; likely caused by an old issue in alien content blocks, fixed ages ago.",task_subcomment,"No reproduction steps; likely caused by an old issue in alien content blocks, fixed ages ago.",BUG REPRODUCTION
242082,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'info' of undefined"" (when saving the page)",Which article did this occur on?,task_subcomment,Which article did this occur on?,ACTION ON ISSUE
53756,VisualEditor: Make it clearer that the clear formatting button does something (clears pre-annotations) if any are set,"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",task_description,"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",BUG REPRODUCTION
241932,VisualEditor: Make it clearer that the clear formatting button does something (clears pre-annotations) if any are set,This was fixed by only showing it as enabled when there's a pre-annnotation stack.,task_subcomment,This was fixed by only showing it as enabled when there's a pre-annnotation stack.,SOLUTION USAGE
241928,VisualEditor: Make it clearer that the clear formatting button does something (clears pre-annotations) if any are set,"Although the interface doesn't clearly indicate this, when the cursor is inside bold text, the toolbar shows ""Bold"" active. When you then click ""Clear formatting"", nothing inside the document will change (since no text is selected) however it does affect text entered from this point on.

Basically when your cursor is inside or against bold text, you'd expect text entered after it will also be bold. Clearing formatting at that point means it will unbold your cursor (if you know what I mean).",task_subcomment,"Although the interface doesn't clearly indicate this, when the cursor is inside bold text, the toolbar shows ""Bold"" active. When you then click ""Clear formatting"", nothing inside the document will change (since no text is selected) however it does affect text entered from this point on.

Basically when your cursor is inside or against bold text, you'd expect text entered after it will also be bold. Clearing formatting at that point means it will unbold your cursor (if you know what I mean).",BUG REPRODUCTION
53752,VisualEditor: In a page with many categories only the first categories are visible in the editor,"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",task_description,"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",BUG REPRODUCTION
241746,VisualEditor: In a page with many categories only the first categories are visible in the editor,This was fixed in August; sorry for the slow triage.,task_subcomment,This was fixed in August; sorry for the slow triage.,ACTION ON ISSUE
53732,VisualEditor: Removal of blank lines when there are HTML comments seems not to work,"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",task_description,"As reported on the Swedish feedback page:
URL

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:

URL

in a way that it gets like this:

URL

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",SOLUTION USAGE
240488,VisualEditor: Removal of blank lines when there are HTML comments seems not to work,"Yes, this is caused by the lack of ability to edit HTML comments making it impossible for users to understand what they're doing; though there are slightly distinct issues here, I'm going to merge it with that feature request.

*** This bug has been marked as a duplicate of bug 49603 ***",task_subcomment,"Yes, this is caused by the lack of ability to edit HTML comments making it impossible for users to understand what they're doing; though there are slightly distinct issues here, I'm going to merge it with that feature request.

*** This bug has been marked as a duplicate of bug 49603 ***",ACTION ON ISSUE
53726,Incorrect URL used for magic RFC links,"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",task_description,"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 URL .

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
240170,Incorrect URL used for magic RFC links,"Change 75118 merged by jenkins-bot:
(Bug 51726) Fixed typo in url base for RFCs

https://gerrit.wikimedia.org/r/75118",task_subcomment,"Change 75118 merged by jenkins-bot:
(Bug 51726) Fixed typo in url base for RFCs

GERRIT_URL",ACTION ON ISSUE
240168,Incorrect URL used for magic RFC links,"Change 75118 had a related patch set uploaded by Subramanya Sastry:
(Bug 51726) Fixed typo in url base for RFCs

https://gerrit.wikimedia.org/r/75118",task_subcomment,"Change 75118 had a related patch set uploaded by Subramanya Sastry:
(Bug 51726) Fixed typo in url base for RFCs

GERRIT_URL",ACTION ON ISSUE
53714,VisualEditor: add new categories after old categories,"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",task_description,"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",SOLUTION DISCUSSION
239615,VisualEditor: add new categories after old categories,"This is a duplicate of the (heretofore-confusingly-named) bug 50882.

*** This bug has been marked as a duplicate of bug 50882 ***",task_subcomment,"This is a duplicate of the (heretofore-confusingly-named) bug 50882.

*** This bug has been marked as a duplicate of bug 50882 ***",ACTION ON ISSUE
53674,VisualEditor: Rearranging transclusions breaks the ability to select parameters.,"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",task_description,"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",BUG REPRODUCTION
237251,VisualEditor: Rearranging transclusions breaks the ability to select parameters.,This was fixed as part of the transclusion dialog re-write in August; sorry for the slow triage.,task_subcomment,This was fixed as part of the transclusion dialog re-write in August; sorry for the slow triage.,ACTION ON ISSUE
237242,VisualEditor: Rearranging transclusions breaks the ability to select parameters.,Also happens on Linux.,task_subcomment,Also happens on Linux.,BUG REPRODUCTION
237235,VisualEditor: Rearranging transclusions breaks the ability to select parameters.,"Addendum: It seems that this does not only affect parameters. If you try to move the templates around more then once it will no longer be possible to rearrange them (The buttons for this no longer work). Also, any template ""Corrupted"" by moving them around will not be added to the page when one presses ""Apply Changes"".",task_subcomment,"Addendum: It seems that this does not only affect parameters. If you try to move the templates around more then once it will no longer be possible to rearrange them (The buttons for this no longer work). Also, any template ""Corrupted"" by moving them around will not be added to the page when one presses ""Apply Changes"".",BUG REPRODUCTION
53655,"VisualEditor: Relabel buttons in ""cancel editing"" confirmation dialog","**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",task_description,"**Author:** CODE

**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: URL See also bug 47676, closed as WONTFIX.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
236185,"VisualEditor: Relabel buttons in ""cancel editing"" confirmation dialog","Merging with bug 50955.

*** This bug has been marked as a duplicate of bug 50955 ***",task_subcomment,"Merging with bug 50955.

*** This bug has been marked as a duplicate of bug 50955 ***",ACTION ON ISSUE
236180,"VisualEditor: Relabel buttons in ""cancel editing"" confirmation dialog","The confirmation dialog should have more descriptive buttons, such as [Discard edits] [Continue editing], or [Leave editing mode] [Return to editing], etc.

For this to happen, it needs to become a jQuery dialog.

In fact, VE shouldn't use native confirm() dialogs; the implementation in most browsers is crappy.",task_subcomment,"The confirmation dialog should have more descriptive buttons, such as [Discard edits] [Continue editing], or [Leave editing mode] [Return to editing], etc.

For this to happen, it needs to become a jQuery dialog.

In fact, VE shouldn't use native confirm() dialogs; the implementation in most browsers is crappy.",SOLUTION DISCUSSION
53653,"VisualEditor: Double-clicking inside edit surface sometimes causes uncaught JS ""offset could not be translated"" errors","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",task_description,"Steps to reproduce:

1) Open URL

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",BUG REPRODUCTION
236087,"VisualEditor: Double-clicking inside edit surface sometimes causes uncaught JS ""offset could not be translated"" errors",I can't reproduce this now' provisionally closing as WORKSFORME. Please re-open if you can still reproduce.,task_subcomment,I can't reproduce this now' provisionally closing as WORKSFORME. Please re-open if you can still reproduce.,WORKAROUNDS
53619,"VisualEditor: ""Leave Feedback"" link greyed out; might confuse users","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",task_description,"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",BUG REPORT
234208,"VisualEditor: ""Leave Feedback"" link greyed out; might confuse users",This design was fixed some time ago but I forgot to tag this bug; sorry!,task_subcomment,This design was fixed some time ago but I forgot to tag this bug; sorry!,ACTION ON ISSUE
53618,"""Leave Feedback"" link rendering as two lines in some fonts","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",task_description,"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?""

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
234164,"""Leave Feedback"" link rendering as two lines in some fonts","This was already reported as bug 51335 (sorry!).

*** This bug has been marked as a duplicate of bug 51335 ***",task_subcomment,"This was already reported as bug 51335 (sorry!).

*** This bug has been marked as a duplicate of bug 51335 ***",BUG REPRODUCTION
53567,VisualEditor: Image is not displayed on Visual Editor,"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",task_description,"The image from [1] and is not rendered on VisualEditor [2].

[1] URL
[2] URL

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",MOTIVATION
255955,VisualEditor: Image is not displayed on Visual Editor,"I believe that this was a dupe of bug 51248.

*** This bug has been marked as a duplicate of bug 51248 ***",task_subcomment,"I believe that this was a dupe of bug 51248.

*** This bug has been marked as a duplicate of bug 51248 ***",ACTION ON ISSUE
53554,"VisualEditor:  tags added to all markup in paragraph, including pre-existing","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  tags around it (correct according to apparent design, incorrect according to desired behaviour). 

However, it also added  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",task_description,"At URL a user added a link using wikitext. The VisualEditor added  tags around it (correct according to apparent design, incorrect according to desired behaviour). 

However, it also added  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",BUG REPRODUCTION
255037,"VisualEditor:  tags added to all markup in paragraph, including pre-existing",This seems to have been fixed (I now can't reproduce) in the re-write of nowiki-ing code; sorry for the bug.,task_subcomment,This seems to have been fixed (I now can't reproduce) in the re-write of nowiki-ing code; sorry for the bug.,SOLUTION DISCUSSION
255030,"VisualEditor:  tags added to all markup in paragraph, including pre-existing","Really sorry, but I meant Bug 50659 comment 5 
Dyslexia + typos to blame so entirely my fault.",task_subcomment,"Really sorry, but I meant Bug 50659 comment 5 
Dyslexia + typos to blame so entirely my fault.",ACTION ON ISSUE
255023,"VisualEditor:  tags added to all markup in paragraph, including pre-existing","Sorry, typo in that last line. It should refer to Bug 50569 comment 5",task_subcomment,"Sorry, typo in that last line. It should refer to Bug 50569 comment 5",ACTION ON ISSUE
53534,Can't save,"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",task_description,"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] URL
[2] File: URL Line: 85
[3] {""servedby"":""mw1203"",""error"":{""code"":""unknownerror"",""info"":""Unknown error: \""tpt-target-page\""""}}

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
253978,Can't save,"

%%%*** This bug has been marked as a duplicate of bug 50284 ***%%%",task_subcomment,"

%%%*** This bug has been marked as a duplicate of bug 50284 ***%%%",ACTION ON ISSUE
253968,Can't save,"...and when I try to edit it using the traditional ""Edit source"" I actually get a real error message: ""This page cannot be updated manually. This page is a translation of the page VisualEditor/Portal and the translation can be updated using the translation tool.""

That message should be shown also when trying to edit with the VisualEditor.",task_subcomment,"...and when I try to edit it using the traditional ""Edit source"" I actually get a real error message: ""This page cannot be updated manually. This page is a translation of the page VisualEditor/Portal and the translation can be updated using the translation tool.""

That message should be shown also when trying to edit with the VisualEditor.",BUG REPRODUCTION
53531,Visual Editor: Adding text after a link includes that text in the link,"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",task_description,"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",BUG REPRODUCTION
253720,Visual Editor: Adding text after a link includes that text in the link,"This is actually the same as bug 51463 which we just fixed and are deploying now. Sorry for the inconvenience.

*** This bug has been marked as a duplicate of bug 51463 ***",task_subcomment,"This is actually the same as bug 51463 which we just fixed and are deploying now. Sorry for the inconvenience.

*** This bug has been marked as a duplicate of bug 51463 ***",ACTION ON ISSUE
253712,Visual Editor: Adding text after a link includes that text in the link,"**JohnCD67** wrote:

This is quite a serious problem because a user who tries to set up a link at the right hand end of a line, i.e. without having first typed at least one space beyond it, becomes trapped in a mode where all further typing goes inside the link, and there is no easy way out. I think this is what is causing peculiar links, e.g. a link to ""Chendo"" piped to ""Chendo, "" and one to ""Manolo Sanchís"" piped to ""Manolo Sanchís and "". See report at

[[:en:WP:VisualEditor/Feedback#You have to type something after a word before attempting to wikilink it]]",task_subcomment,"**JohnCD67** wrote:

This is quite a serious problem because a user who tries to set up a link at the right hand end of a line, i.e. without having first typed at least one space beyond it, becomes trapped in a mode where all further typing goes inside the link, and there is no easy way out. I think this is what is causing peculiar links, e.g. a link to ""Chendo"" piped to ""Chendo, "" and one to ""Manolo Sanchís"" piped to ""Manolo Sanchís and "". See report at

[[:en:WP:VisualEditor/Feedback#You have to type something after a word before attempting to wikilink it]]",BUG REPRODUCTION
53530,VisualEditor: Tab key moves focus between citations; doesn't indent text as expected,"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",task_description,"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",BUG REPRODUCTION
253661,VisualEditor: Tab key moves focus between citations; doesn't indent text as expected,"

*** This bug has been marked as a duplicate of bug 48010 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 48010 ***",ACTION ON ISSUE
53528,"VisualEditor: Inserting whitespace in front of a paragraph shouldn't convert the paragraph to a preformatted block, but also shouldn't leave unneeded s","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",task_description,"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. URL

*It turned the first word into an uneditable element. See image: URL 

*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."" URL

* It allowed me to remove the space in VE.


(Also using Chrome on 7.)

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
253588,"VisualEditor: Inserting whitespace in front of a paragraph shouldn't convert the paragraph to a preformatted block, but also shouldn't leave unneeded s",This was fixed in July; sorry for the slow triage.,task_subcomment,This was fixed in July; sorry for the slow triage.,ACTION ON ISSUE
53514,update.php does not give any response.,"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:

    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]#

    
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",task_description,"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:

    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]#

    
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",BUG REPRODUCTION
252854,update.php does not give any response.,"Find out reason. For some unknown reason, the php does not shows error message. When one of my friend tried 

php -n update.php

it showed the error message and we fix it very soon according to it.",task_subcomment,"Find out reason. For some unknown reason, the php does not shows error message. When one of my friend tried 

php -n update.php

it showed the error message and we fix it very soon according to it.",BUG REPRODUCTION
252847,update.php does not give any response.,"The most annoying thing is when I tried to upgrade same database to 1.22wmf9 on other vps, all of then works as normal.",task_subcomment,"The most annoying thing is when I tried to upgrade same database to 1.22wmf9 on other vps, all of then works as normal.",SOLUTION USAGE
252840,update.php does not give any response.,"BTW, I tried 1.20.6 and 1.21.1 as well. None of them work in that server.",task_subcomment,"BTW, I tried 1.20.6 and 1.21.1 as well. None of them work in that server.",BUG REPRODUCTION
53481,&veaction= as a second parameter works on enwiki but not zhwiki,"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",task_description,"Dunno why but:

URL loads VE-edit mode

URL doesn't.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
250734,&veaction= as a second parameter works on enwiki but not zhwiki,"(In reply to comment #2)
> Do you perhaps have the VE preference enabled on enwiki but not on zhwiki?
> veaction=edit will only work if VisualEditor is available, i.e. you didn't
> disable it and it didn't detect some problem with your browser that made it
> disable itself.

Well it works for me now on zhwiki.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE

Well it works for me now on zhwiki.",WORKAROUNDS
250728,&veaction= as a second parameter works on enwiki but not zhwiki,"Do you perhaps have the VE preference enabled on enwiki but not on zhwiki? veaction=edit will only work if VisualEditor is available, i.e. you didn't disable it and it didn't detect some problem with your browser that made it disable itself.",task_subcomment,"Do you perhaps have the VE preference enabled on enwiki but not on zhwiki? veaction=edit will only work if VisualEditor is available, i.e. you didn't disable it and it didn't detect some problem with your browser that made it disable itself.",SOLUTION USAGE
250721,&veaction= as a second parameter works on enwiki but not zhwiki,I cant reproduce this now.,task_subcomment,I cant reproduce this now.,BUG REPRODUCTION
53456,"Rearranging, removing, or reorganizing sections, then saving the page, causes the Table of Contents to link to 'Edit' instead of the section","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",task_description,"From URL

""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",BUG REPRODUCTION
249290,"Rearranging, removing, or reorganizing sections, then saving the page, causes the Table of Contents to link to 'Edit' instead of the section","I still cannot replicate this; possibly a transient caching bug?

Marking as INVALID. Please re-open if it recurs.",task_subcomment,"I still cannot replicate this; possibly a transient caching bug?

Marking as INVALID. Please re-open if it recurs.",BUG REPRODUCTION
249285,"Rearranging, removing, or reorganizing sections, then saving the page, causes the Table of Contents to link to 'Edit' instead of the section","fwiw, I also tried to replicate it back in July and failed.",task_subcomment,"fwiw, I also tried to replicate it back in July and failed.",BUG REPRODUCTION
53453,VisualEditor:Wrong reference subnumbering used for some wikis,"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}",task_description,"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}",BUG REPRODUCTION
249176,VisualEditor:Wrong reference subnumbering used for some wikis,"This is covered by bug 49346 which is assigned and prioritised, so I'm marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 49346 ***",task_subcomment,"This is covered by bug 49346 which is assigned and prioritised, so I'm marking this as a duplicate.

*** This bug has been marked as a duplicate of bug 49346 ***",ACTION ON ISSUE
249172,VisualEditor:Wrong reference subnumbering used for some wikis,"(In reply to comment #1)
> (Are the letters in ref.1 at
> https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/
> Sandbox&diff=next&oldid=570373191
> different from what you describe?)

In read mode I see

1. ^ a b pippo

In VE edit mode I see:

1.   1.0 1.1 pippo

The latter is wrong. I except to see in VE edit mode the same letters a b as in read mode",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE

In read mode I see

1. ^ a b pippo

In VE edit mode I see:

1.   1.0 1.1 pippo

The latter is wrong. I except to see in VE edit mode the same letters a b as in read mode",BUG REPRODUCTION
249167,VisualEditor:Wrong reference subnumbering used for some wikis,(Are the letters in ref.1 at https://en.wikipedia.org/w/index.php?title=User:Elitre_(WMF)/Sandbox&diff=next&oldid=570373191 different from what you describe?),task_subcomment,(Are the letters in ref.1 at URL different from what you describe?),INVESTIGATION AND EXPLORATION
53452,VisualEditor: Category adding interface is hard to find,"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",task_description,"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",FUTURE PLAN
249101,VisualEditor: Category adding interface is hard to find,"

*** This bug has been marked as a duplicate of bug 51153 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 51153 ***",ACTION ON ISSUE
249097,VisualEditor: Category adding interface is hard to find,"Nevermind. I found it under Page Settings. Seems like a strange place to put it. I would expect page settings to be stuff like font size or disabling the table of contents. Also the gear icon seems like a strange choice since all of our other uses of the gear icon (Echo, ULS) are about changing user preferences. Definitely not an icon I would associate with adding categories.

Changing bug summary.",task_subcomment,"Nevermind. I found it under Page Settings. Seems like a strange place to put it. I would expect page settings to be stuff like font size or disabling the table of contents. Also the gear icon seems like a strange choice since all of our other uses of the gear icon (Echo, ULS) are about changing user preferences. Definitely not an icon I would associate with adding categories.

Changing bug summary.",SOLUTION USAGE
53440,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'end' of null""","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",task_description,"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.


QUOTE
  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",BUG REPRODUCTION
248308,"VisualEditor: Fix ""Uncaught TypeError: Cannot read property 'end' of null""",Provisionally closing as WORKSFORME.,task_subcomment,Provisionally closing as WORKSFORME.,ACTION ON ISSUE
53438,VisualEditor: Link inspector should make it easier to change the label,"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 link
 Select link (has to be done manually (tedious and error prone) 
 > Some [selection]    link[/selection]""
 Type ""hello"".
 > Some hello.

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 ""first charother chars"" case.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=48463",task_description,"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:

QUOTE
 Select link (has to be done manually (tedious and error prone) 
QUOTE
 Type ""hello"".
QUOTE

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 ""first charother chars"" case.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",SOLUTION DISCUSSION
248200,VisualEditor: Link inspector should make it easier to change the label,"

*** This bug has been marked as a duplicate of bug 53973 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 53973 ***",ACTION ON ISSUE
248194,VisualEditor: Link inspector should make it easier to change the label,"Here's a link that shows one of the main problems with the current approach:  https://hif.wikipedia.org/w/index.php?title=Akbar_the_Great&diff=194531&oldid=194146

The editor almost certainly did not intend to end up with [[15 October|14 October]], and the editor almost certainly does not know that his effort to change the link failed.",task_subcomment,"Here's a link that shows one of the main problems with the current approach:  URL

The editor almost certainly did not intend to end up with [[15 October|14 October]], and the editor almost certainly does not know that his effort to change the link failed.",INVESTIGATION AND EXPLORATION
248190,VisualEditor: Link inspector should make it easier to change the label,"I'd rather have a label input (or at least a label display) in the link inspector, but some method of indicating that the link is piped or has separate trailing text is important.  

If you see a redlink like ""Alice Expert"", you can't tell from looking at the link in VisualEditor that it's actually piped:  [[Alice D Expert|Alice Expert]].  Fixing the label to match the actual article title name (""Alice D. Expert"") does not fix the broken link.  

There's no way to see that the redlink didn't get fixed when you changed the label to ""Alice D. Expert"" (because VisualEditor's ""red"" links are blue).  

There is also no reason for you to suspect that the problem is due to a hidden piped link, because there is no visual cue that you need to go into the link inspector to address the hidden/piped link.",task_subcomment,"I'd rather have a label input (or at least a label display) in the link inspector, but some method of indicating that the link is piped or has separate trailing text is important.  

If you see a redlink like ""Alice Expert"", you can't tell from looking at the link in VisualEditor that it's actually piped:  [[Alice D Expert|Alice Expert]].  Fixing the label to match the actual article title name (""Alice D. Expert"") does not fix the broken link.  

There's no way to see that the redlink didn't get fixed when you changed the label to ""Alice D. Expert"" (because VisualEditor's ""red"" links are blue).  

There is also no reason for you to suspect that the problem is due to a hidden piped link, because there is no visual cue that you need to go into the link inspector to address the hidden/piped link.",SOLUTION DISCUSSION
248188,VisualEditor: Link inspector should make it easier to change the label,I think this duplicates Bug 50945,task_subcomment,I think this duplicates Bug 50945,BUG REPRODUCTION
248186,VisualEditor: Link inspector should make it easier to change the label,"We shouldn't put a label input in the link inspector because:

1. It doesn't support rich text
2. We cannot and should not put a subsurface in an inspector
3. Links should remain a lightweight task, and dialogs are not lightweight
4. This doesn't elegantly solve the problem anyway

Some steps towards a better approach:

1. We could decorate the ""linked"" portion of a link differently than
   the link trail portion - at lease during certain interactions.
2. We could add extra cursor positions on each side of a link to indicate being
   next to or inside the link tag, decorate the link when you are inside those
   boundaries.",task_subcomment,"We shouldn't put a label input in the link inspector because:

1. It doesn't support rich text
2. We cannot and should not put a subsurface in an inspector
3. Links should remain a lightweight task, and dialogs are not lightweight
4. This doesn't elegantly solve the problem anyway

Some steps towards a better approach:

1. We could decorate the ""linked"" portion of a link differently than
   the link trail portion - at lease during certain interactions.
2. We could add extra cursor positions on each side of a link to indicate being
   next to or inside the link tag, decorate the link when you are inside those
   boundaries.",SOLUTION DISCUSSION
53427,Syndicated feeds of Watchlists include non-existent edits,"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}",task_description,"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}",BUG REPRODUCTION
247612,Syndicated feeds of Watchlists include non-existent edits,This seems fixed now for me.,task_subcomment,This seems fixed now for me.,BUG REPRODUCTION
247607,Syndicated feeds of Watchlists include non-existent edits,"Core should exclude RC_EXTERNAL by default for feeds or the extension has to provide a feed formatter for that row, but should also respect the setting, that external not always include in the result.

You can use wltype=edit|new|log to exclude the external edits.",task_subcomment,"Core should exclude RC_EXTERNAL by default for feeds or the extension has to provide a feed formatter for that row, but should also respect the setting, that external not always include in the result.

You can use wltype=edit|new|log to exclude the external edits.",SOLUTION USAGE
247602,Syndicated feeds of Watchlists include non-existent edits,"Problem solved? This user edited d:Q3977961 (several times in a row: https://www.wikidata.org/w/index.php?title=Q3977961&diff=60842173&oldid=37167299 ). Evidently, related items from Wikidata cause these phantom changes to occur...",task_subcomment,"Problem solved? This user edited d:Q3977961 (several times in a row: URL ). Evidently, related items from Wikidata cause these phantom changes to occur...",SOLUTION USAGE
247597,Syndicated feeds of Watchlists include non-existent edits,"For what it's worth, I just caught a live one showing up in my Special:Watchlist Atom feed and then checked against Special:RecentChanges on en.wp:

At 1:23, my watchlist claims that User:Andreasmperu edited Superman (The Clique song).

Here is a copy-and-paste from every edit that happened from 1:23:00 to 1:23:59:

(diff | hist) . . Begusarai district‎; 01:23:59 . . (+19)‎ . . ‎101.62.52.201 (talk)‎ (→‎Education)
(diff | hist) . . Wikipedia:WikiProject Guild of Copy Editors/Backlog elimination drives/July 2013‎; 01:23:58 . . (+59)‎ . . ‎JudyCS (talk | contribs)‎ (→‎JudyCS (talk): updated totals)
(diff | hist) . . Kojak‎; 01:23:57 . . (+14)‎ . . ‎71.180.138.175 (talk)‎ (→‎Plot) [rollback]
(diff | hist) . . N User:TinyURLDotComSlashMb4tstl‎; 01:23:55 . . (+27)‎ . . ‎Prolog (talk | contribs)‎ (blockedsock)
(diff | hist) . . N! User:Djdubay/sandbox/Userbox/Project‎; 01:23:53 . . (+802)‎ . . ‎Djdubay (talk | contribs)‎ (Creating new sandbox subpage.)
(diff | hist) . . Wikipedia:WikiProject Military history/Fortifications task force/Popular pages‎; 01:23:52 . . (-30)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Military history/Fortifications task force) [rollback]
(diff | hist) . . User:DGG/CSD log‎; 01:23:51 . . (+166)‎ . . ‎DGG (talk | contribs)‎ (Logging speedy deletion nomination of Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND. (TW])) [rollback]
(diff | hist) . . Margareta Huitfeldt‎; 01:23:49 . . (+66)‎ . . ‎Aciram (talk | contribs)‎ (→‎References) [rollback]
(diff | hist) . . m Stella Women’s Academy, High School Division Class C3‎; 01:23:47 . . (+20)‎ . . ‎Xezbeth (talk | contribs)‎ (Disambiguated: Rambo → Rambo (film series)) [rollback]
(diff | hist) . . N. T. Rama Rao Jr.‎; 01:23:47 . . (-12)‎ . . ‎117.241.0.199 (talk)‎ (→‎As actor) [rollback]
(User creation log); 01:23:45 . . User account Thundercatmd (talk | contribs) was created ‎
(diff | hist) . . Sadabad, India‎; 01:23:45 . . (+77)‎ . . ‎117.243.196.54 (talk)‎ (→‎Education) [rollback]
(diff | hist) . . Crestar Bank‎; 01:23:42 . . (0)‎ . . ‎173.71.136.155 (talk)‎
(diff | hist) . . Template:Did you know nominations/Russian submarine K-18 Karelia‎; 01:23:40 . . (+350)‎ . . ‎Daniel Case (talk | contribs)‎ (dull hook) [rollback]
(diff | hist) . . Aubrey Plaza‎; 01:23:40 . . (+46)‎ . . ‎Captain Assassin! (talk | contribs)‎ (Life After Beth) [rollback]
(diff | hist) . . WVQS-LD‎; 01:23:39 . . (-1)‎ . . ‎142.255.235.18 (talk)‎ [rollback]
(User creation log); 01:23:39 . . User account Reginawong71 (talk | contribs) was created ‎
(diff | hist) . . Wikipedia:Categories for discussion/Log/2013 July 9‎; 01:23:38 . . (+312)‎ . . ‎DexDor (talk | contribs)‎ (→‎Category:Modern surface-to-air missiles: cmt) [rollback]
(diff | hist) . . Richard Lee McNair‎; 01:23:37 . . (0)‎ . . ‎Download (talk | contribs)‎ (→‎Attempts to avoid recapture: caps)
(diff | hist) . . Wikipedia:WikiProject Motorcycling/Popular pages‎; 01:23:36 . . (+2)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Motorcycling) [rollback]
(diff | hist) . . User:Aghaz Tech Systems‎; 01:23:35 . . (+16)‎ . . ‎I am One of Many (talk | contribs)‎ (Requesting speedy deletion (CSD G11). (TW)) [rollback]
(diff | hist) . . Akkineni Nageswara Rao‎; 01:23:34 . . (-12)‎ . . ‎DMacks (talk | contribs)‎ (MOS) [rollback]
(diff | hist) . . Prince William, Duke of Cambridge‎; 01:23:33 . . (+400)‎ . . ‎71.167.157.25 (talk)‎ (→‎Royal duties: tidies) [rollback]
(diff | hist) . . User talk:Praghadeshkar‎; 01:23:32 . . (+1,977)‎ . . ‎DGG (talk | contribs)‎ (Notification: speedy deletion nomination of Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND. (TW])) [rollback]
(diff | hist) . . N! Wikipedia:Articles for creation/RJ Sridharan‎; 01:23:32 . . (+5,171)‎ . . ‎Anandhi1212 (talk | contribs)‎ (←Created page with ''''RJ Sridharan''' Rajendram Jagannathan Sridharan, affectionately addressed as Com RJS by the Indian banking fraternity was born on April 9th, 1949. He was bor...')
(diff | hist) . . Seoul Metropolitan Police Agency‎; 01:23:30 . . (+95)‎ . . ‎Howard61313 (talk | contribs)‎ [rollback]
(diff | hist) . . Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND‎; 01:23:30 . . (+12)‎ . . ‎DGG (talk | contribs)‎ (Requesting speedy deletion (CSD G11). (TW])) [rollback]
(diff | hist) . . Gabrielle Union‎; 01:23:29 . . (-3)‎ . . ‎Monkelese (talk | contribs)‎ [rollback]
(diff | hist) . . Kashmere Stage Band‎; 01:23:28 . . (-57)‎ . . ‎107.196.30.182 (talk)‎ (→‎History) [rollback]
(Article Feedback Activity Log); 01:23:28 . . 122.178.233.254 (talk) submitted feedback post #050027e... on Dhanush ‎(i am happy to be a fan of dhanush)
(diff | hist) . . Fahadh Faasil‎; 01:23:28 . . (+103)‎ . . ‎92.97.8.139 (talk)‎ (→‎Filmography)
(diff | hist) . . m Waldemar Klingelhöfer‎; 01:23:24 . . (-1)‎ . . ‎Robert4565 (talk | contribs)‎ (Tag: VisualEditor) [rollback]
(diff | hist) . . m Maiden's Tower‎; 01:23:23 . . (+3)‎ . . ‎Thewolfchild (talk | contribs)‎ (→‎Legend) [rollback]
(diff | hist) . . Ball State University‎; 01:23:23 . . (-276)‎ . . ‎184.17.231.231 (talk)‎ (removed Points of interest section → all places are listed in Ball State navigation box and/or are mentioned throughout the article) (Tag: section blanking) [rollback]
(diff | hist) . . m Adas Israel Congregation (Washington, D.C.)‎; 01:23:21 . . (+37)‎ . . ‎Bizzurp (talk | contribs)‎ (Category:Conservative synagogues) [rollback]
(diff | hist) . . Wikipedia:WikiProject Arthropods/Popular pages‎; 01:23:21 . . (+12)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Arthropods) [rollback]
(diff | hist) . . Animethon‎; 01:23:19 . . (-103)‎ . . ‎Ceasol (talk | contribs)‎ (Animethon has become largest Anime Convention with an attendance in 2012 of 6404 against Anime Revolution with 5233) (Tag: VisualEditor) [rollback]
(diff | hist) . . Talk:Sex at Dawn‎; 01:23:17 . . (+245)‎ . . ‎NorthBySouthBaranof (talk | contribs)‎ (→‎Removal of Ellsworth's ""Sex at Dusk"" review)
(diff | hist) . . N! User:MOTOI Kenkichi/北乃カムイ‎; 01:23:17 . . (+5,636)‎ . . ‎MOTOI Kenkichi (talk | contribs)‎ (翻訳用テンプレ)
(diff | hist) . . m William Fulton (urban planner)‎; 01:23:16 . . (+4)‎ . . ‎Billfulton00 (talk | contribs)‎ (Tag: VisualEditor) [rollback]
(Protection log); 01:23:16 . . Prolog (talk | contribs) protected Patient Protection and Affordable Care Act‎ ‎[edit=autoconfirmed] (expires 05:23, 30 July 2013 (UTC)) ‎[move=autoconfirmed] (expires 05:23, 30 July 2013 (UTC)) ‎(Persistent sock puppetry)
(diff | hist) . . Barbro Eriksdotter (Bielke)‎; 01:23:14 . . (+32)‎ . . ‎Aciram (talk | contribs)‎ (→‎Sources) [rollback]
(diff | hist) . . Ohio State Route 357‎; 01:23:14 . . (+94)‎ . . ‎CycloneIsaac (talk | contribs)‎ (→‎References: separate) [rollback]
(diff | hist) . . Gwangju FC‎; 01:23:12 . . (+69)‎ . . ‎Z4617925 (talk | contribs)‎ (→‎Current squad) [rollback]
(diff | hist) . . N Talk:Lavender Country‎; 01:23:12 . . (+419)‎ . . ‎Bearcat (talk | contribs)‎ (←Created page with '{{Old AfD|Lavender Country|delete}} ==Prior AFD== Please note that this version of the article is significantly expanded, and its sourcing significant...')
(diff | hist) . . Argentine legislative election, 2013‎; 01:23:12 . . (-59)‎ . . ‎186.61.49.196 (talk)‎
(diff | hist) . . Brian Nieves‎; 01:23:08 . . (+14)‎ . . ‎PaulinSaudi (talk | contribs)‎ (fix many capitals) [rollback]
(diff | hist) . . SeaWorld Entertainment‎; 01:23:07 . . (+17)‎ . . ‎67.238.188.192 (talk)‎ (Tag: VisualEditor) [rollback]
(diff | hist) . . British Expedition to Abyssinia‎; 01:23:05 . . (+7)‎ . . ‎Reenem (talk | contribs)‎ (→‎The campaign) [rollback]
(User creation log); 01:23:04 . . User account Rblak87 (talk | contribs) was created ‎
(diff | hist) . . Arunachal Pradesh‎; 01:23:04 . . (-1,141)‎ . . ‎BijoyChakrabarty (talk | contribs)‎ (Undid revision 565431133 by Qwyrxian (talk) Hindi is not official language in Arunachal pradesh, it's English. Official Gov cite provided) [rollback]
(diff | hist) . . Wikipedia:WikiProject Solar System/Popular pages‎; 01:23:03 . . (-17)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Solar System) [rollback]
(diff | hist) . . Wikipedia:Huggle/Users‎; 01:23:03 . . (+38)‎ . . ‎Czar (talk | contribs)‎ (Adding czar (HG)) [rollback]
(User creation log); 01:23:01 . . User account Huskers3155 (talk | contribs) was created ‎
(diff | hist) . . m Southern Cross All-Stars‎; 01:23:01 . . (+31)‎ . . ‎Loudestpenguin (talk | contribs)‎ (Tag: VisualEditor)
(diff | hist) . . Talk:List of tallest buildings in Christchurch‎; 01:23:00 . . (+282)‎ . . ‎Grutness (talk | contribs)‎ (→‎Minimum height)",task_subcomment,"For what it's worth, I just caught a live one showing up in my Special:Watchlist Atom feed and then checked against Special:RecentChanges on en.wp:

At 1:23, my watchlist claims that User:Andreasmperu edited Superman (The Clique song).

Here is a copy-and-paste from every edit that happened from 1:23:00 to 1:23:59:

(diff | hist) . . Begusarai district‎; 01:23:59 . . (+19)‎ . . ‎101.62.52.201 (talk)‎ (→‎Education)
(diff | hist) . . Wikipedia:WikiProject Guild of Copy Editors/Backlog elimination drives/July 2013‎; 01:23:58 . . (+59)‎ . . ‎JudyCS (talk | contribs)‎ (→‎JudyCS (talk): updated totals)
(diff | hist) . . Kojak‎; 01:23:57 . . (+14)‎ . . ‎71.180.138.175 (talk)‎ (→‎Plot) [rollback]
(diff | hist) . . N User:TinyURLDotComSlashMb4tstl‎; 01:23:55 . . (+27)‎ . . ‎Prolog (talk | contribs)‎ (blockedsock)
(diff | hist) . . N! User:Djdubay/sandbox/Userbox/Project‎; 01:23:53 . . (+802)‎ . . ‎Djdubay (talk | contribs)‎ (Creating new sandbox subpage.)
(diff | hist) . . Wikipedia:WikiProject Military history/Fortifications task force/Popular pages‎; 01:23:52 . . (-30)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Military history/Fortifications task force) [rollback]
(diff | hist) . . User:DGG/CSD log‎; 01:23:51 . . (+166)‎ . . ‎DGG (talk | contribs)‎ (Logging speedy deletion nomination of Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND. (TW])) [rollback]
(diff | hist) . . Margareta Huitfeldt‎; 01:23:49 . . (+66)‎ . . ‎Aciram (talk | contribs)‎ (→‎References) [rollback]
(diff | hist) . . m Stella Women’s Academy, High School Division Class C3‎; 01:23:47 . . (+20)‎ . . ‎Xezbeth (talk | contribs)‎ (Disambiguated: Rambo → Rambo (film series)) [rollback]
(diff | hist) . . N. T. Rama Rao Jr.‎; 01:23:47 . . (-12)‎ . . ‎117.241.0.199 (talk)‎ (→‎As actor) [rollback]
(User creation log); 01:23:45 . . User account Thundercatmd (talk | contribs) was created ‎
(diff | hist) . . Sadabad, India‎; 01:23:45 . . (+77)‎ . . ‎117.243.196.54 (talk)‎ (→‎Education) [rollback]
(diff | hist) . . Crestar Bank‎; 01:23:42 . . (0)‎ . . ‎173.71.136.155 (talk)‎
(diff | hist) . . Template:Did you know nominations/Russian submarine K-18 Karelia‎; 01:23:40 . . (+350)‎ . . ‎Daniel Case (talk | contribs)‎ (dull hook) [rollback]
(diff | hist) . . Aubrey Plaza‎; 01:23:40 . . (+46)‎ . . ‎Captain Assassin! (talk | contribs)‎ (Life After Beth) [rollback]
(diff | hist) . . WVQS-LD‎; 01:23:39 . . (-1)‎ . . ‎142.255.235.18 (talk)‎ [rollback]
(User creation log); 01:23:39 . . User account Reginawong71 (talk | contribs) was created ‎
(diff | hist) . . Wikipedia:Categories for discussion/Log/2013 July 9‎; 01:23:38 . . (+312)‎ . . ‎DexDor (talk | contribs)‎ (→‎Category:Modern surface-to-air missiles: cmt) [rollback]
(diff | hist) . . Richard Lee McNair‎; 01:23:37 . . (0)‎ . . ‎Download (talk | contribs)‎ (→‎Attempts to avoid recapture: caps)
(diff | hist) . . Wikipedia:WikiProject Motorcycling/Popular pages‎; 01:23:36 . . (+2)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Motorcycling) [rollback]
(diff | hist) . . User:Aghaz Tech Systems‎; 01:23:35 . . (+16)‎ . . ‎I am One of Many (talk | contribs)‎ (Requesting speedy deletion (CSD G11). (TW)) [rollback]
(diff | hist) . . Akkineni Nageswara Rao‎; 01:23:34 . . (-12)‎ . . ‎DMacks (talk | contribs)‎ (MOS) [rollback]
(diff | hist) . . Prince William, Duke of Cambridge‎; 01:23:33 . . (+400)‎ . . ‎71.167.157.25 (talk)‎ (→‎Royal duties: tidies) [rollback]
(diff | hist) . . User talk:Praghadeshkar‎; 01:23:32 . . (+1,977)‎ . . ‎DGG (talk | contribs)‎ (Notification: speedy deletion nomination of Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND. (TW])) [rollback]
(diff | hist) . . N! Wikipedia:Articles for creation/RJ Sridharan‎; 01:23:32 . . (+5,171)‎ . . ‎Anandhi1212 (talk | contribs)‎ (←Created page with ''''RJ Sridharan''' Rajendram Jagannathan Sridharan, affectionately addressed as Com RJS by the Indian banking fraternity was born on April 9th, 1949. He was bor...')
(diff | hist) . . Seoul Metropolitan Police Agency‎; 01:23:30 . . (+95)‎ . . ‎Howard61313 (talk | contribs)‎ [rollback]
(diff | hist) . . Wikipedia talk:Articles for creation/TPRG KANGAROO BRAND‎; 01:23:30 . . (+12)‎ . . ‎DGG (talk | contribs)‎ (Requesting speedy deletion (CSD G11). (TW])) [rollback]
(diff | hist) . . Gabrielle Union‎; 01:23:29 . . (-3)‎ . . ‎Monkelese (talk | contribs)‎ [rollback]
(diff | hist) . . Kashmere Stage Band‎; 01:23:28 . . (-57)‎ . . ‎107.196.30.182 (talk)‎ (→‎History) [rollback]
(Article Feedback Activity Log); 01:23:28 . . 122.178.233.254 (talk) submitted feedback post #050027e... on Dhanush ‎(i am happy to be a fan of dhanush)
(diff | hist) . . Fahadh Faasil‎; 01:23:28 . . (+103)‎ . . ‎92.97.8.139 (talk)‎ (→‎Filmography)
(diff | hist) . . m Waldemar Klingelhöfer‎; 01:23:24 . . (-1)‎ . . ‎Robert4565 (talk | contribs)‎ (Tag: VisualEditor) [rollback]
(diff | hist) . . m Maiden's Tower‎; 01:23:23 . . (+3)‎ . . ‎Thewolfchild (talk | contribs)‎ (→‎Legend) [rollback]
(diff | hist) . . Ball State University‎; 01:23:23 . . (-276)‎ . . ‎184.17.231.231 (talk)‎ (removed Points of interest section → all places are listed in Ball State navigation box and/or are mentioned throughout the article) (Tag: section blanking) [rollback]
(diff | hist) . . m Adas Israel Congregation (Washington, D.C.)‎; 01:23:21 . . (+37)‎ . . ‎Bizzurp (talk | contribs)‎ (Category:Conservative synagogues) [rollback]
(diff | hist) . . Wikipedia:WikiProject Arthropods/Popular pages‎; 01:23:21 . . (+12)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Arthropods) [rollback]
(diff | hist) . . Animethon‎; 01:23:19 . . (-103)‎ . . ‎Ceasol (talk | contribs)‎ (Animethon has become largest Anime Convention with an attendance in 2012 of 6404 against Anime Revolution with 5233) (Tag: VisualEditor) [rollback]
(diff | hist) . . Talk:Sex at Dawn‎; 01:23:17 . . (+245)‎ . . ‎NorthBySouthBaranof (talk | contribs)‎ (→‎Removal of Ellsworth's ""Sex at Dusk"" review)
(diff | hist) . . N! User:MOTOI Kenkichi/北乃カムイ‎; 01:23:17 . . (+5,636)‎ . . ‎MOTOI Kenkichi (talk | contribs)‎ (翻訳用テンプレ)
(diff | hist) . . m William Fulton (urban planner)‎; 01:23:16 . . (+4)‎ . . ‎Billfulton00 (talk | contribs)‎ (Tag: VisualEditor) [rollback]
(Protection log); 01:23:16 . . Prolog (talk | contribs) protected Patient Protection and Affordable Care Act‎ ‎[edit=autoconfirmed] (expires 05:23, 30 July 2013 (UTC)) ‎[move=autoconfirmed] (expires 05:23, 30 July 2013 (UTC)) ‎(Persistent sock puppetry)
(diff | hist) . . Barbro Eriksdotter (Bielke)‎; 01:23:14 . . (+32)‎ . . ‎Aciram (talk | contribs)‎ (→‎Sources) [rollback]
(diff | hist) . . Ohio State Route 357‎; 01:23:14 . . (+94)‎ . . ‎CycloneIsaac (talk | contribs)‎ (→‎References: separate) [rollback]
(diff | hist) . . Gwangju FC‎; 01:23:12 . . (+69)‎ . . ‎Z4617925 (talk | contribs)‎ (→‎Current squad) [rollback]
(diff | hist) . . N Talk:Lavender Country‎; 01:23:12 . . (+419)‎ . . ‎Bearcat (talk | contribs)‎ (←Created page with '{{Old AfD|Lavender Country|delete}} ==Prior AFD== Please note that this version of the article is significantly expanded, and its sourcing significant...')
(diff | hist) . . Argentine legislative election, 2013‎; 01:23:12 . . (-59)‎ . . ‎186.61.49.196 (talk)‎
(diff | hist) . . Brian Nieves‎; 01:23:08 . . (+14)‎ . . ‎PaulinSaudi (talk | contribs)‎ (fix many capitals) [rollback]
(diff | hist) . . SeaWorld Entertainment‎; 01:23:07 . . (+17)‎ . . ‎67.238.188.192 (talk)‎ (Tag: VisualEditor) [rollback]
(diff | hist) . . British Expedition to Abyssinia‎; 01:23:05 . . (+7)‎ . . ‎Reenem (talk | contribs)‎ (→‎The campaign) [rollback]
(User creation log); 01:23:04 . . User account Rblak87 (talk | contribs) was created ‎
(diff | hist) . . Arunachal Pradesh‎; 01:23:04 . . (-1,141)‎ . . ‎BijoyChakrabarty (talk | contribs)‎ (Undid revision 565431133 by Qwyrxian (talk) Hindi is not official language in Arunachal pradesh, it's English. Official Gov cite provided) [rollback]
(diff | hist) . . Wikipedia:WikiProject Solar System/Popular pages‎; 01:23:03 . . (-17)‎ . . ‎Mr.Z-bot (talk | contribs)‎ (Popularity stats for WikiProject Solar System) [rollback]
(diff | hist) . . Wikipedia:Huggle/Users‎; 01:23:03 . . (+38)‎ . . ‎Czar (talk | contribs)‎ (Adding czar (HG)) [rollback]
(User creation log); 01:23:01 . . User account Huskers3155 (talk | contribs) was created ‎
(diff | hist) . . m Southern Cross All-Stars‎; 01:23:01 . . (+31)‎ . . ‎Loudestpenguin (talk | contribs)‎ (Tag: VisualEditor)
(diff | hist) . . Talk:List of tallest buildings in Christchurch‎; 01:23:00 . . (+282)‎ . . ‎Grutness (talk | contribs)‎ (→‎Minimum height)",SOLUTION DISCUSSION
247591,Syndicated feeds of Watchlists include non-existent edits,"Recent changes for this article (according to toolserver.org):

mysql> select * from recentchanges where rc_namespace = 0 and rc_title = 'Everything_That_Happens_Will_Happen_Today' order by rc_id desc limit 2 \G
*************************** 1. row ***************************
        rc_id: 590682778
 rc_timestamp: 20130715213627
  rc_cur_time: 20130715213627
      rc_user: 0
 rc_user_text: FelGru
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: 
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562841657
      rc_type: 5
 rc_patrolled: 1
   rc_old_len: 131636
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params: a:1:{s:20:""wikibase-repo-change"";a:13:{s:2:""id"";i:56980275;s:4:""type"";s:20:""wikibase-item~update"";s:4:""time"";s:14:""20130715213627"";s:9:""object_id"";s:5:""q6336"";s:7:""user_id"";i:180688;s:11:""revision_id"";i:58328008;s:11:""entity_type"";s:4:""item"";s:9:""user_text"";s:6:""FelGru"";s:3:""bot"";i:0;s:7:""page_id"";i:7449;s:6:""rev_id"";i:58328008;s:9:""parent_id"";i:58327906;s:7:""comment"";s:23:""wikibase-comment-update"";}}
*************************** 2. row ***************************
        rc_id: 588688216
 rc_timestamp: 20130704145433
  rc_cur_time: 20130704145433
      rc_user: 205121
 rc_user_text: Koavf
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: fmt
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562815320
      rc_type: 0
 rc_patrolled: 0
   rc_old_len: 131440
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params:",task_subcomment,"Recent changes for this article (according to toolserver.org):

mysql> select * from recentchanges where rc_namespace = 0 and rc_title = 'Everything_That_Happens_Will_Happen_Today' order by rc_id desc limit 2 \G
*************************** 1. row ***************************
        rc_id: 590682778
 rc_timestamp: 20130715213627
  rc_cur_time: 20130715213627
      rc_user: 0
 rc_user_text: FelGru
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: 
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562841657
      rc_type: 5
 rc_patrolled: 1
   rc_old_len: 131636
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params: a:1:{s:20:""wikibase-repo-change"";a:13:{s:2:""id"";i:56980275;s:4:""type"";s:20:""wikibase-item~update"";s:4:""time"";s:14:""20130715213627"";s:9:""object_id"";s:5:""q6336"";s:7:""user_id"";i:180688;s:11:""revision_id"";i:58328008;s:11:""entity_type"";s:4:""item"";s:9:""user_text"";s:6:""FelGru"";s:3:""bot"";i:0;s:7:""page_id"";i:7449;s:6:""rev_id"";i:58328008;s:9:""parent_id"";i:58327906;s:7:""comment"";s:23:""wikibase-comment-update"";}}
*************************** 2. row ***************************
        rc_id: 588688216
 rc_timestamp: 20130704145433
  rc_cur_time: 20130704145433
      rc_user: 205121
 rc_user_text: Koavf
 rc_namespace: 0
     rc_title: Everything_That_Happens_Will_Happen_Today
   rc_comment: fmt
     rc_minor: 1
       rc_bot: 0
       rc_new: 0
    rc_cur_id: 18622850
rc_this_oldid: 562841657
rc_last_oldid: 562815320
      rc_type: 0
 rc_patrolled: 0
   rc_old_len: 131440
   rc_new_len: 131636
   rc_deleted: 0
     rc_logid: 0
  rc_log_type: NULL
rc_log_action: 
        rc_ip: 
    rc_params:",SOLUTION DISCUSSION
247586,Syndicated feeds of Watchlists include non-existent edits,"Also, checking https://en.wikipedia.org/wiki/Special:Watchlist does not display these non-existent edits nor does the page history of the individual articles and categories mentioned.",task_subcomment,"Also, checking URL does not display these non-existent edits nor does the page history of the individual articles and categories mentioned.",BUG REPRODUCTION
53422,Adding formatting to wiki link formats text not link,"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",task_description,"See URL

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",BUG REPRODUCTION
247312,Adding formatting to wiki link formats text not link,"This is the same as bug 50098, yes; merging.

(In reply to comment #1)
> It has been noted today that VE still has issues with large pages, so it
> really
> shouldn't be adding unnecessary bytes to a page like this.

The length of a page's wikitext has no direct impact on VisualEditor's performance; it's the length and complexity of the HTML that's in question. In this case, the HTML is identical, so this has no performance impact.

*** This bug has been marked as a duplicate of bug 50098 ***",task_subcomment,"This is the same as bug 50098, yes; merging.

(In reply to comment #1)
QUOTE
QUOTE
QUOTE

The length of a page's wikitext has no direct impact on VisualEditor's performance; it's the length and complexity of the HTML that's in question. In this case, the HTML is identical, so this has no performance impact.

*** This bug has been marked as a duplicate of bug 50098 ***",ACTION ON ISSUE
247304,Adding formatting to wiki link formats text not link,"As I wrote in 50098, to avoid [[Foo|''Bar'']] you should italicize first, and link only after
that. I added this to the Italian User guide and I am looking for other similar tips I might be missing.
Thanks.",task_subcomment,"As I wrote in 50098, to avoid [[Foo|''Bar'']] you should italicize first, and link only after
that. I added this to the Italian User guide and I am looking for other similar tips I might be missing.
Thanks.",SOLUTION USAGE
247295,Adding formatting to wiki link formats text not link,"It has been noted today that VE still has issues with large pages, so it really shouldn't be adding unnecessary bytes to a page like this.",task_subcomment,"It has been noted today that VE still has issues with large pages, so it really shouldn't be adding unnecessary bytes to a page like this.",BUG REPRODUCTION
53417,Blanking last section of page corrupts heading,"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",task_description,"Reported here: URL

IP editor removes contents from last section of page.  VE replaces heading text with nowiki.

Diff:URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
246916,Blanking last section of page corrupts heading,"

%%%*** This bug has been marked as a duplicate of bug 50100 ***%%%",task_subcomment,"

%%%*** This bug has been marked as a duplicate of bug 50100 ***%%%",ACTION ON ISSUE
53409,color picker,"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",task_description,"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)

URL

--------------------------
**Version**: unspecified
**Severity**: enhancement",SOLUTION USAGE
246442,color picker,"

*** This bug has been marked as a duplicate of bug 52645 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 52645 ***",ACTION ON ISSUE
53389,Disabling VisualEditor completely,"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",task_description,"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",SOLUTION USAGE
245136,Disabling VisualEditor completely,"In general, VE questions should be filed on [[WP:VE/F]] as that is the best place to give feedback for the VisualEditor.

This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 50929 ***",task_subcomment,"In general, VE questions should be filed on [[WP:VE/F]] as that is the best place to give feedback for the VisualEditor.

This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 50929 ***",ACTION ON ISSUE
53369,VisualEditor: spurious parentheses added,"See https://en.wikipedia.org/w/index.php?title=Wormshill&diff=564367057&oldid=557770558 for example.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See URL for example.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244045,VisualEditor: spurious parentheses added,"This is caused by an unbalanced 
     in the infobox, which ""works"" (ish) in MediaWiki's PHP parser but didn't in Parsoid at the time; this is subsequently worked around. Closing as WORKSFORME.",task_subcomment,"This is caused by an unbalanced 
     in the infobox, which ""works"" (ish) in MediaWiki's PHP parser but didn't in Parsoid at the time; this is subsequently worked around. Closing as WORKSFORME.",WORKAROUNDS
53366,504 timeout with Parsoid service,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
243919,504 timeout with Parsoid service,"**brunsa2** wrote:

I've upgrades both VisualEditor and Parsoid, after converting wiki installation to  use SSL and then turning it off, Parsoid spontaneously started working.",task_subcomment,"**brunsa2** wrote:

I've upgrades both VisualEditor and Parsoid, after converting wiki installation to  use SSL and then turning it off, Parsoid spontaneously started working.",SOLUTION USAGE
243915,504 timeout with Parsoid service,See http://www.mediawiki.org/wiki/MediaWiki_on_IRC for information on IRC.,task_subcomment,See URL for information on IRC.,ACTION ON ISSUE
243910,504 timeout with Parsoid service,Please come on #mediawiki-parsoid IRC channel to debug these issues.  It appears that Parsoid might be having trouble connecting with your mediawiki instance.,task_subcomment,Please come on #mediawiki-parsoid IRC channel to debug these issues.  It appears that Parsoid might be having trouble connecting with your mediawiki instance.,ACTION ON ISSUE
53364,VisualEditor: Edit this Page button ignores &oldid=prev parameter.,"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",task_description,"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 URL
* 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",BUG REPRODUCTION
243826,VisualEditor: Edit this Page button ignores &oldid=prev parameter.,This seems to now be fixed. Please re-open if you think I'm wrong!,task_subcomment,This seems to now be fixed. Please re-open if you think I'm wrong!,ISSUE CONTENT MANAGEMENT
243821,VisualEditor: Edit this Page button ignores &oldid=prev parameter.,"Preference 'Do not show page content below diffs' also affects this bug.

If enabled, the 'Edit source' link currently edits the current version of the page, so I think 'Edit' is doing the right thing in that case.

If disabled, the diff block on the page should be deleted and the html on the page should be editable as-is.",task_subcomment,"Preference 'Do not show page content below diffs' also affects this bug.

If enabled, the 'Edit source' link currently edits the current version of the page, so I think 'Edit' is doing the right thing in that case.

If disabled, the diff block on the page should be deleted and the html on the page should be editable as-is.",SOLUTION USAGE
53356,Add ULS language setting dialogue box in VisualEditor page settings,"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",task_description,"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
URL

	

Thanks and Warm Regards

--------------------------
**Version**: unspecified
**Severity**: enhancement",SOLUTION DISCUSSION
243369,Add ULS language setting dialogue box in VisualEditor page settings,"Closing as invalid for now. I think what is implicit here, is present explicitly in other, unreferenced issues.",task_subcomment,"Closing as invalid for now. I think what is implicit here, is present explicitly in other, unreferenced issues.",ACTION ON ISSUE
243363,Add ULS language setting dialogue box in VisualEditor page settings,"(In reply to comment #5)

What Mr. Amir discussing higher end facilities are welcome.

As far as this bug is concrned simply this bug intends/requests for basic feature requirement provide ULS input method selection at VE tool bar. sans any icons . As of now ULS icons have not been understood by 60% of targeted new user group.VE tool bar is right in front of eyes I can select every thing including intended language input from VE tool bar itself before I start editing, this I am looking for . Am I asking for some thing too much and too defficult ?",task_subcomment,"(In reply to comment #5)

What Mr. Amir discussing higher end facilities are welcome.

As far as this bug is concrned simply this bug intends/requests for basic feature requirement provide ULS input method selection at VE tool bar. sans any icons . As of now ULS icons have not been understood by 60% of targeted new user group.VE tool bar is right in front of eyes I can select every thing including intended language input from VE tool bar itself before I start editing, this I am looking for . Am I asking for some thing too much and too defficult ?",SOLUTION USAGE
243356,Add ULS language setting dialogue box in VisualEditor page settings,Mahitgar: Could you please answer comment 5?,task_subcomment,Mahitgar: Could you please answer comment 5?,ACTION ON ISSUE
243350,Add ULS language setting dialogue box in VisualEditor page settings,"ULS is a flexible tool for selecting a language out of a long list of possible languages. It may or may not be relevant for this request.

The ULS may be used in the future for switching to Wikipedia in another language; I refer to the thing that is done today with the interlanguage links.

Setting a different content language for a whole page is a useful feature, and the ULS can be used for selecting the language there, but first the MediaWiki core must support it; see Bug 9360. It is also mentioned in the i18n specification for VE: https://www.mediawiki.org/wiki/VisualEditor/Internationalization_requirements .

To summarize: Mahitgar, can you please write *what* are you asking to do? ULS may or may not be the a good *way* to do it, but first the actual feature must be defined. I tried to read the the thread, and I didn't quite understand the requirement.",task_subcomment,"ULS is a flexible tool for selecting a language out of a long list of possible languages. It may or may not be relevant for this request.

The ULS may be used in the future for switching to Wikipedia in another language; I refer to the thing that is done today with the interlanguage links.

Setting a different content language for a whole page is a useful feature, and the ULS can be used for selecting the language there, but first the MediaWiki core must support it; see Bug 9360. It is also mentioned in the i18n specification for VE: URL .

To summarize: Mahitgar, can you please write *what* are you asking to do? ULS may or may not be the a good *way* to do it, but first the actual feature must be defined. I tried to read the the thread, and I didn't quite understand the requirement.",SOLUTION DISCUSSION
243343,Add ULS language setting dialogue box in VisualEditor page settings,Im not sure this is desirable or not; adding people and tracking to help sort that out.  Is runa@wikimedia.org on bugzilla yet?,task_subcomment,Im not sure this is desirable or not; adding people and tracking to help sort that out.  Is runa@wikimedia.org on bugzilla yet?,ACTION ON ISSUE
243339,Add ULS language setting dialogue box in VisualEditor page settings,So far this report does not explain which problem you would like to solve by this.,task_subcomment,So far this report does not explain which problem you would like to solve by this.,SOLUTION DISCUSSION
243335,Add ULS language setting dialogue box in VisualEditor page settings,"Created attachment 12858
Request for ULS language settings in VE page settings-languages

Request for ULS language settings link in VE page settings-languages .When clicked should open up ULS dialogue box for language settings

**Attached**: {F11465}",task_subcomment,"Created attachment 12858
Request for ULS language settings in VE page settings-languages

Request for ULS language settings link in VE page settings-languages .When clicked should open up ULS dialogue box for language settings

**Attached**: {F11465}",ACTION ON ISSUE
243329,Add ULS language setting dialogue box in VisualEditor page settings,"(In reply to comment #0)
> 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

Please provide a screenshot of the current problem that you would like to
solve, plus a link to reproduce. 
Also see https://www.mediawiki.org/wiki/How_to_report_a_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_2
> 8864

Please summarize the points made there instead of making me read a long thread.",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Please provide a screenshot of the current problem that you would like to
solve, plus a link to reproduce. 
Also see URL

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Please summarize the points made there instead of making me read a long thread.",ACTION ON ISSUE
53354,ULS input options visibility in VE with a drop down menu,"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",task_description,"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
URL 


Thanks and Warm Regards

--------------------------
**Version**: unspecified
**Severity**: enhancement",SOLUTION DISCUSSION
243199,ULS input options visibility in VE with a drop down menu,"Hi Mahitgar. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 49569 ***",task_subcomment,"Hi Mahitgar. Thanks for taking the time to report this!
This particular problem has already been reported into our bug tracking system, but please feel free to report any further issues you find.

*** This bug has been marked as a duplicate of bug 49569 ***",ACTION ON ISSUE
243194,ULS input options visibility in VE with a drop down menu,"Created attachment 12855
Example Needed ULS input method dropdown menu at VisualEditor.toolbar

**Attached**: {F11453}",task_subcomment,"Created attachment 12855
Example Needed ULS input method dropdown menu at VisualEditor.toolbar

**Attached**: {F11453}",ACTION ON ISSUE
243191,ULS input options visibility in VE with a drop down menu,"(In reply to comment #0)
> 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.  

It is unclear to me what is requested here. Could you please provide steps to reproduce as a numbered list, click by click, plus the current outcome, and the outcome that you expect?
Also see https://www.mediawiki.org/wiki/How_to_report_a_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_2
> 8864 

Please summarize the points made there instead of making me read a long thread.",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

It is unclear to me what is requested here. Could you please provide steps to reproduce as a numbered list, click by click, plus the current outcome, and the outcome that you expect?
Also see URL

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Please summarize the points made there instead of making me read a long thread.",ACTION ON ISSUE
53343,VisualEditor: Automatically add title of the section to edit summary,"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",task_description,"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",SOLUTION DISCUSSION
242555,VisualEditor: Automatically add title of the section to edit summary,"This is the same as bug 50872; merging.

*** This bug has been marked as a duplicate of bug 50872 ***",task_subcomment,"This is the same as bug 50872; merging.

*** This bug has been marked as a duplicate of bug 50872 ***",ACTION ON ISSUE
242550,VisualEditor: Automatically add title of the section to edit summary,"**ignatzmice.wiki** wrote:

I agree with Michael, this would be very useful.",task_subcomment,"**ignatzmice.wiki** wrote:

I agree with Michael, this would be very useful.",SOLUTION DISCUSSION
53341,"VisualEditor: double-clicking ""create reference"" generates a quasi-broken ref form.","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}",task_description,"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}",BUG REPRODUCTION
242434,"VisualEditor: double-clicking ""create reference"" generates a quasi-broken ref form.",This has been fixed since July; sorry for slow update.,task_subcomment,This has been fixed since July; sorry for slow update.,SOLUTION USAGE
53340,VisualEditor: Applying a transclusion that only contains content brackets breaks the edit toolbar.,"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",task_description,"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",BUG REPRODUCTION
242400,VisualEditor: Applying a transclusion that only contains content brackets breaks the edit toolbar.,We fixed this quite some time ago; apologies for the slowness of updating this bug report.,task_subcomment,We fixed this quite some time ago; apologies for the slowness of updating this bug report.,ACTION ON ISSUE
242397,VisualEditor: Applying a transclusion that only contains content brackets breaks the edit toolbar.,*** Bug 51437 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51437 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
53332,VisualEditor: Deletion of alienated content blocks can delete across (rather than deleting them),"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",task_description,"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 (URL
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",BUG REPRODUCTION
241991,VisualEditor: Deletion of alienated content blocks can delete across (rather than deleting them),This was fixed in the re-work of selection and deletion recently; sorry for the slow triage.,task_subcomment,This was fixed in the re-work of selection and deletion recently; sorry for the slow triage.,SOLUTION USAGE
53311,Allow wikitext e.g. links to documentation in templatedata,"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",task_description,"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
URL
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**:
URL",SOLUTION DISCUSSION
240797,Allow wikitext e.g. links to documentation in templatedata,"

*** This bug has been marked as a duplicate of bug 50656 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50656 ***",ACTION ON ISSUE
240795,Allow wikitext e.g. links to documentation in templatedata,*** Bug 50656 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50656 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
240791,Allow wikitext e.g. links to documentation in templatedata,"At [https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564196505#Quotes_in_template_data] there is a related request to allow wikitext generally in Template Data documentation. 

The specific request for the example given there is the  tag to all better distinguishing of '' (two apostrophes for italic markup) and "" (double quote) by rendering them in a monospace font.",task_subcomment,"At [URL there is a related request to allow wikitext generally in Template Data documentation. 

The specific request for the example given there is the  tag to all better distinguishing of '' (two apostrophes for italic markup) and "" (double quote) by rendering them in a monospace font.",SOLUTION USAGE
53280,VisualEditor: External link missing in template due to linkname with ampersand in it,"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",task_description,"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: URL

So possible entity escaping problem

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
239102,VisualEditor: External link missing in template due to linkname with ampersand in it,confirmed,task_subcomment,confirmed,TASK PROGRESS
239092,VisualEditor: External link missing in template due to linkname with ampersand in it,I think this has been subsequently fixed - can you confirm?,task_subcomment,I think this has been subsequently fixed - can you confirm?,SOLUTION USAGE
53249,VisualEditor: Interface has elements untranslated in Spanish,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
237026,VisualEditor: Interface has elements untranslated in Spanish,"[Sorry for bad auto-translation.]

La traducción de la interfaz del software se realiza en TranslateWiki.Net.

Puede ver todos los mensajes traducidas existentes para VisualEditor en Español
en:

http://translatewiki.net/w/i.php?title=Special:Translate&language=es&group=ext-visualeditor

Estoy de acuerdo en que hay demasiados mensajes sin traducir.

Para convertirse en un traductor de sí mismo, por favor vaya a:


https://translatewiki.net/w/i.php?title=Special:UserLogin&returnto=Special%3AFirstSteps&type=signup&uselang=es",task_subcomment,"[Sorry for bad auto-translation.]

La traducción de la interfaz del software se realiza en TranslateWiki.Net.

Puede ver todos los mensajes traducidas existentes para VisualEditor en Español
en:

URL

Estoy de acuerdo en que hay demasiados mensajes sin traducir.

Para convertirse en un traductor de sí mismo, por favor vaya a:


URL",MOTIVATION
237022,VisualEditor: Interface has elements untranslated in Spanish,"Translation of the software interface is done on TranslateWiki.Net.

You can see all the existing untranslated messages for VisualEditor in Spanish at:

 http://translatewiki.net/w/i.php?title=Special:Translate&language=es&group=ext-visualeditor

I agree that there are too many untranslated messages.

To become a translator yourself, please go to:

  https://translatewiki.net/w/i.php?title=Special:UserLogin&returnto=Special%3AFirstSteps&type=signup&uselang=es",task_subcomment,"Translation of the software interface is done on TranslateWiki.Net.

You can see all the existing untranslated messages for VisualEditor in Spanish at:

 URL

I agree that there are too many untranslated messages.

To become a translator yourself, please go to:

  URL",SOLUTION USAGE
53244,VisualEditor: Images disappear when the editor is loaded,"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",task_description,"Compare
1) URL
2) URL

There are two images in the first case, but they disappear in the second case.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
236659,VisualEditor: Images disappear when the editor is loaded,"Per http://parsoid.wmflabs.org/pt/Usu%C3%A1rio:Helder.wiki/Testes?oldid=36380720 the images have been replaced by Parsoid with  which is why they don't appear. This is apparently caused by bug 48900 - merging with that.

*** This bug has been marked as a duplicate of bug 48900 ***",task_subcomment,"Per URL the images have been replaced by Parsoid with  which is why they don't appear. This is apparently caused by bug 48900 - merging with that.

*** This bug has been marked as a duplicate of bug 48900 ***",ACTION ON ISSUE
236652,VisualEditor: Images disappear when the editor is loaded,"Parsoid just adds a missing space in the [link syntax]:
http://parsoid.wmflabs.org/_rt/pt/?oldid=36380720",task_subcomment,"Parsoid just adds a missing space in the [link syntax]:
URL",SOLUTION USAGE
53220,VisualEditor: Cut and Pasting a section that contains an image truncates all the sections formatting after pasting it.,"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",task_description,"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 URL 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",BUG REPRODUCTION
235424,VisualEditor: Cut and Pasting a section that contains an image truncates all the sections formatting after pasting it.,"And marking as a duplicate of bug 33105, which is about supporting this functionality.

The cut operation should probably be 'disabled' if it contains elements that can't be pasted again.  However the 'cut' operation could do a 'copy' operation, with a notice to the user that cut is not supported for complex wiki blocks.

The paste operation should probably be disabled until this is fixed, with a notice to the user that they should press undo/Control-Z to get back their text if the last item on the undo stack is a Cut operation.

But there is probably also an 'enhancement' raised about those as well.

*** This bug has been marked as a duplicate of bug 33105 ***",task_subcomment,"And marking as a duplicate of bug 33105, which is about supporting this functionality.

The cut operation should probably be 'disabled' if it contains elements that can't be pasted again.  However the 'cut' operation could do a 'copy' operation, with a notice to the user that cut is not supported for complex wiki blocks.

The paste operation should probably be disabled until this is fixed, with a notice to the user that they should press undo/Control-Z to get back their text if the last item on the undo stack is a Cut operation.

But there is probably also an 'enhancement' raised about those as well.

*** This bug has been marked as a duplicate of bug 33105 ***",SOLUTION DISCUSSION
235419,VisualEditor: Cut and Pasting a section that contains an image truncates all the sections formatting after pasting it.,Confirming your example.,task_subcomment,Confirming your example.,TASK PROGRESS
235414,VisualEditor: Cut and Pasting a section that contains an image truncates all the sections formatting after pasting it.,See also https://bugzilla.wikimedia.org/show_bug.cgi?id=50721,task_subcomment,See also URL,ACTION ON ISSUE
53200,Botfixup: VisualEditor shows 6 items in a list which for which MW only generates 2 items,"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",task_description,"Compare the result of the wikitext
#1
#
#
#
#
#6
in the following URLs:
1) URL
2) URL

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",BUG REPRODUCTION
234299,Botfixup: VisualEditor shows 6 items in a list which for which MW only generates 2 items,"It would be difficult to sanely edit undisplayed list items. We would basically have to pretend those list items were never there. They would not be editable in the VE. 

While not impossible, even round-tripping of such collapsed list items would add a lot of special-case code.

So overall I am very doubtful that this would be worth it. IMO it is better to fix the wikitext, possibly with a bot. I'm closing this as wontfix for now. Please reopen if there are good reasons why correcting this with bots is not feasible.",task_subcomment,"It would be difficult to sanely edit undisplayed list items. We would basically have to pretend those list items were never there. They would not be editable in the VE. 

While not impossible, even round-tripping of such collapsed list items would add a lot of special-case code.

So overall I am very doubtful that this would be worth it. IMO it is better to fix the wikitext, possibly with a bot. I'm closing this as wontfix for now. Please reopen if there are good reasons why correcting this with bots is not feasible.",SOLUTION DISCUSSION
234290,Botfixup: VisualEditor shows 6 items in a list which for which MW only generates 2 items,This is in Parsoid: http://parsoid.wmflabs.org/pt/Usu%C3%A1rio:Lechatjaune/Testes?oldid=36373624,task_subcomment,This is in Parsoid: URL,BUG REPRODUCTION
53191,Template rearranging itself,"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.

    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",task_description,"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. [URL Here] is what happened.

    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",BUG REPRODUCTION
233796,Template rearranging itself,This was the Parsoid complex templates / VisualEditor dirtying edits bug that got fixed months ago; sorry for the very slow triage.,task_subcomment,This was the Parsoid complex templates / VisualEditor dirtying edits bug that got fixed months ago; sorry for the very slow triage.,BUG REPRODUCTION
53188,Template editing within referencing is complex to the point of hampering usability,"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",task_description,"See URL

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",SOLUTION USAGE
233670,Template editing within referencing is complex to the point of hampering usability,"Merging this in with bug 50768.

*** This bug has been marked as a duplicate of bug 50768 ***",task_subcomment,"Merging this in with bug 50768.

*** This bug has been marked as a duplicate of bug 50768 ***",ACTION ON ISSUE
233663,Template editing within referencing is complex to the point of hampering usability,Another editor has created a potential workflow for references. See http://en.wikipedia.org/wiki/User:Looie496/VE_Reference_editor,task_subcomment,Another editor has created a potential workflow for references. See URL,POTENTIAL NEW ISSUES AND REQUESTS
53183,"VisualEditor: Design of the reference re-use pane is confusing, with a bold ""Use an existing source"" title that doesn't look like one","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",task_description,"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",SOLUTION DISCUSSION
233481,"VisualEditor: Design of the reference re-use pane is confusing, with a bold ""Use an existing source"" title that doesn't look like one",This was fixed some months ago in the re-work of the transclusion dialog; sorry for the slowness of reply.,task_subcomment,This was fixed some months ago in the re-work of the transclusion dialog; sorry for the slowness of reply.,ACTION ON ISSUE
53175,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","**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",task_description,"**Author:** CODE

**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 URL 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",BUG REPRODUCTION
233175,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","**kwwilliams** wrote:

It's 51150.",task_subcomment,"**kwwilliams** wrote:

It's 51150.",ACTION ON ISSUE
233168,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","You have a choice of bug here, but it will be either 51150 (dirty diff) or 51003 (match style for new parameters and use appropriate style for new transclusions).

Bug 51150 seems to be rare these days when you look at the VE recentchanges diffs, but there still seem to be some recent examples of it occuring, which is why it was reopened.

VE recent changes on enwiki:
https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&limit=100&tagfilter=visualeditor",task_subcomment,"You have a choice of bug here, but it will be either 51150 (dirty diff) or 51003 (match style for new parameters and use appropriate style for new transclusions).

Bug 51150 seems to be rare these days when you look at the VE recentchanges diffs, but there still seem to be some recent examples of it occuring, which is why it was reopened.

VE recent changes on enwiki:
URL",BUG REPRODUCTION
233161,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","**kwwilliams** wrote:

This is *not* a duplicate of 51003. You need to maintain the original formatting, not any suggested formatting. If the original source lists the parameters like

{{name
|arg1|arg2
|arg3
|arg4
|arg5
}}

and someone changes arg2, all that should occur is that the value of arg2 should be changed. No braces should move. No newlines should be inserted or removed. The ""dirty diff"" is *precisely* what I am complaining about.

The various bugs around allowing a suggested format are all valid, but this isn't a duplicate. Diff lists are how we detect what editors have changed, and anything that dirties a diff is generally a bad thing. Reformatting templates when an argument is modified causes dirty diffs.",task_subcomment,"**kwwilliams** wrote:

This is *not* a duplicate of 51003. You need to maintain the original formatting, not any suggested formatting. If the original source lists the parameters like

{{name
|arg1|arg2
|arg3
|arg4
|arg5
}}

and someone changes arg2, all that should occur is that the value of arg2 should be changed. No braces should move. No newlines should be inserted or removed. The ""dirty diff"" is *precisely* what I am complaining about.

The various bugs around allowing a suggested format are all valid, but this isn't a duplicate. Diff lists are how we detect what editors have changed, and anything that dirties a diff is generally a bad thing. Reformatting templates when an argument is modified causes dirty diffs.",BUG REPRODUCTION
233156,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","In that case this is duplicate of bug 51003.

*** This bug has been marked as a duplicate of bug 51003 ***",task_subcomment,"In that case this is duplicate of bug 51003.

*** This bug has been marked as a duplicate of bug 51003 ***",ACTION ON ISSUE
233152,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read",The dirty diff is not the question here. Clarifying title.,task_subcomment,The dirty diff is not the question here. Clarifying title.,TASK PROGRESS
233149,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","**wicke** wrote:

Looks like VE bug 51150. Closing as duplicate.

%%%*** This bug has been marked as a duplicate of bug 51150 ***%%%",task_subcomment,"**wicke** wrote:

Looks like VE bug 51150. Closing as duplicate.

%%%*** This bug has been marked as a duplicate of bug 51150 ***%%%",ACTION ON ISSUE
233145,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","I think the idea of a TemplateData tag as to whether to keep new lines seems like a good one, if Parsoid would be interested.",task_subcomment,"I think the idea of a TemplateData tag as to whether to keep new lines seems like a good one, if Parsoid would be interested.",SOLUTION DISCUSSION
233141,"Parsoid does not add newlines between parameters in new template invocations, making wikitext difficult to read","Agreed; this is true for existing templates, but it's also an issue when adding a long infobox to a page, for example.

It was suggested by French Wikipedians to add a tag to TemplateData (like '""collapsed"" = false') that would indicate to VisualEditor that the community consensus for a given template is to have one parameter per line, instead of cramming everything together (which could remain as the default behavior, and makes sense for many short templates).",task_subcomment,"Agreed; this is true for existing templates, but it's also an issue when adding a long infobox to a page, for example.

It was suggested by French Wikipedians to add a tag to TemplateData (like '""collapsed"" = false') that would indicate to VisualEditor that the community consensus for a given template is to have one parameter per line, instead of cramming everything together (which could remain as the default behavior, and makes sense for many short templates).",SOLUTION DISCUSSION
53173, added to wikilinks,"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",task_description,"In URL 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 URL 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**:
URL",BUG REPRODUCTION
232892, added to wikilinks,"If the user selects ""diesel generator"" (i.e., misses the 's'), the resultant HTML would be

  diesel generators 

The correct wikitext version of this is indeed

  [[diesel generator]]s

… which is probably not what the user wanted to do, but it appears to be what they asked VisualEditor to do.

Consequently, I'm going to mark this as INVALID [If this is not the case - that the user did indeed select the entirety of the two words and there's a bug, I'd really love to know what browser they were using so we can hunt down the problem in our selection code!]

Had they instead selected ""diesel generators"", VisualEditor/Parsoid would have created this as:

  [[diesel generator|diesel generators]]

… which is not ideal (I'd prefer the shorter [[diesel generator]]s) but does the job. (I've just triple-checked this in Firefox, Chrome and Safari - it doesn't appear to have broken.)

We could always expand users' selections to what we think they should have selected, but this would make it impossible for users to do some things that they may want to do, albeit less frequently. I'm not sure that preventing users from doing things that they can do in wikitext would be a good solution, in general.",task_subcomment,"If the user selects ""diesel generator"" (i.e., misses the 's'), the resultant HTML would be

  diesel generators 

The correct wikitext version of this is indeed

  [[diesel generator]]s

… which is probably not what the user wanted to do, but it appears to be what they asked VisualEditor to do.

Consequently, I'm going to mark this as INVALID [If this is not the case - that the user did indeed select the entirety of the two words and there's a bug, I'd really love to know what browser they were using so we can hunt down the problem in our selection code!]

Had they instead selected ""diesel generators"", VisualEditor/Parsoid would have created this as:

  [[diesel generator|diesel generators]]

… which is not ideal (I'd prefer the shorter [[diesel generator]]s) but does the job. (I've just triple-checked this in Firefox, Chrome and Safari - it doesn't appear to have broken.)

We could always expand users' selections to what we think they should have selected, but this would make it impossible for users to do some things that they may want to do, albeit less frequently. I'm not sure that preventing users from doing things that they can do in wikitext would be a good solution, in general.",INVESTIGATION AND EXPLORATION
53169,VisualEditor: blanking an article and starting from scratch causes malformations,"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",task_description,"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",BUG REPRODUCTION
232672,VisualEditor: blanking an article and starting from scratch causes malformations,"This is the same as bug 50947, I believe - merging.

*** This bug has been marked as a duplicate of bug 50947 ***",task_subcomment,"This is the same as bug 50947, I believe - merging.

*** This bug has been marked as a duplicate of bug 50947 ***",ACTION ON ISSUE
232665,VisualEditor: blanking an article and starting from scratch causes malformations,"I'm seeing something very slightly different to this - see https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=563808463#Odd_bug_after_blanking_page

If it matters I'm using Firefox 22 on Xubuntu Linux. I don't have another browser to test it in (Konqueror is apparently blacklisted from VE).",task_subcomment,"I'm seeing something very slightly different to this - see URL

If it matters I'm using Firefox 22 on Xubuntu Linux. I don't have another browser to test it in (Konqueror is apparently blacklisted from VE).",BUG REPRODUCTION
232656,VisualEditor: blanking an article and starting from scratch causes malformations,"I reported something similar in Bug 50947, though there I couldn't type at all. Roan asked for JS console output there, so I guess that it would be useful here, too.

This may also be browser-specific.",task_subcomment,"I reported something similar in Bug 50947, though there I couldn't type at all. Roan asked for JS console output there, so I guess that it would be useful here, too.

This may also be browser-specific.",BUG REPRODUCTION
232648,VisualEditor: blanking an article and starting from scratch causes malformations,"Screenshot

**Attached**: {F11062}",task_subcomment,"Screenshot

**Attached**: {F11062}",BUG REPRODUCTION
53165,VisualEditor: easier parameter selection,"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",task_description,"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",SOLUTION USAGE
232451,VisualEditor: easier parameter selection,"Per my previous comment I'm marking this as a duplicate of bug 51143. Feel free to reopen if this is still not working anywhere.

*** This bug has been marked as a duplicate of bug 51143 ***",task_subcomment,"Per my previous comment I'm marking this as a duplicate of bug 51143. Feel free to reopen if this is still not working anywhere.

*** This bug has been marked as a duplicate of bug 51143 ***",ACTION ON ISSUE
232443,VisualEditor: easier parameter selection,I think this can be marked as a duplicate of resolved bug 51143 they seem similar and double-clicking a parameter name does insert the parameter for me.,task_subcomment,I think this can be marked as a duplicate of resolved bug 51143 they seem similar and double-clicking a parameter name does insert the parameter for me.,BUG REPRODUCTION
232435,VisualEditor: easier parameter selection,"(I think I had reported something similar, but still :) )
Users @itwp also ask for drop-down menu or similar solution in order to choose between values (i.e. gender (M/F) and so on).",task_subcomment,"(I think I had reported something similar, but still :) )
UsersSCREEN_NAME also ask for drop-down menu or similar solution in order to choose between values (i.e. gender (M/F) and so on).",SOLUTION DISCUSSION
53153,VisualEditor: Category interface is hard to find,"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",task_description,"Finding the categories under page setting is non intuitive. Adding another icon next to references would help usability.

This is discussed at URL

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",SOLUTION USAGE
231669,VisualEditor: Category interface is hard to find,"We now split this out into the page settings menu, so closing as INVALID given the evolution of the interface.",task_subcomment,"We now split this out into the page settings menu, so closing as INVALID given the evolution of the interface.",ISSUE CONTENT MANAGEMENT
231664,VisualEditor: Category interface is hard to find,"So hard to find that I assumed it wasn't implemented yet. Now I've seen it.

Why another icon on the top and not direct manipulation at the bottom? Show the categories at the bottom of the page and allow adding / editing / deleting from there. More or less the way HotCat got us used, if possible with a cleaner UI.",task_subcomment,"So hard to find that I assumed it wasn't implemented yet. Now I've seen it.

Why another icon on the top and not direct manipulation at the bottom? Show the categories at the bottom of the page and allow adding / editing / deleting from there. More or less the way HotCat got us used, if possible with a cleaner UI.",SOLUTION USAGE
231659,VisualEditor: Category interface is hard to find,"See also:
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Categories
and
https://www.mediawiki.org/wiki/Thread:VisualEditor/Feedback/Smaller_popup_dialog_for_Category_labeling_on_pages?",task_subcomment,"See also:
URL
and
URL",SOLUTION USAGE
231655,VisualEditor: Category interface is hard to find,*** Bug 51452 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51452 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
53134,VisualEditor: Intermittently unable to open page settings after deleting and then adding a stub template,"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",task_description,"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 URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
254897,VisualEditor: Intermittently unable to open page settings after deleting and then adding a stub template,I can't reproduce this now; provisionally marking as WORKSFORME.,task_subcomment,I can't reproduce this now; provisionally marking as WORKSFORME.,WORKAROUNDS
254895,VisualEditor: Intermittently unable to open page settings after deleting and then adding a stub template,"I've just tried reproducing this again, and it is still happening and still only intermittently (2 of 4 articles I tried)",task_subcomment,"I've just tried reproducing this again, and it is still happening and still only intermittently (2 of 4 articles I tried)",BUG REPRODUCTION
53132,VisualEditor: Auto-generated (bare) external links converted to external links to target null,"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,[null http:///www.icmacabre.blogspot.com]

----

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",task_description,"VisualEditor appears to be inserting ""null"" into external links occasionally.

Examples:

URL

at [[Ithaca College]] in [[Ithaca, New York]] by the Macabre Theatre Ensemble,[null URL

----

URL

Delphi has large communities on [[Usenet]] and the [[World Wide Web|web]] (e.g. [null news://newsgroups.codegear.com)] which

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION DISCUSSION
254811,VisualEditor: Auto-generated (bare) external links converted to external links to target null,"This was an icky bug that we fixed some time ago; sorry for the bug, and for the slowness of triage.",task_subcomment,"This was an icky bug that we fixed some time ago; sorry for the bug, and for the slowness of triage.",ACTION ON ISSUE
53130,VisualEditor: Removing template & Adding content breaks editor,"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",task_description,"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",BUG REPRODUCTION
254719,VisualEditor: Removing template & Adding content breaks editor,"Bug 51340 is essentially the same issue, and both are now fixed I believe.",task_subcomment,"Bug 51340 is essentially the same issue, and both are now fixed I believe.",BUG REPRODUCTION
53125,"VisualEditor: Review changes should show the edit summary, if one has been provided.","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",task_description,"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",SOLUTION USAGE
254543,"VisualEditor: Review changes should show the edit summary, if one has been provided.","(In reply to comment #1)
> I think this duplicates bug 42139

Yeah; merging.

*** This bug has been marked as a duplicate of bug 42139 ***",task_subcomment,"(In reply to comment #1)
QUOTE

Yeah; merging.

*** This bug has been marked as a duplicate of bug 42139 ***",ACTION ON ISSUE
254537,"VisualEditor: Review changes should show the edit summary, if one has been provided.",I think this duplicates bug 42139,task_subcomment,I think this duplicates bug 42139,BUG REPRODUCTION
53119,Transcluded pages quasi-template eats into subsequent entry,"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",task_description,"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:

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
254294,Transcluded pages quasi-template eats into subsequent entry,Opened Parsoid bug 53368 for the issues described in comment #12 above.,task_subcomment,Opened Parsoid bug 53368 for the issues described in comment #12 above.,ACTION ON ISSUE
254289,Transcluded pages quasi-template eats into subsequent entry,"A deeper investigation revealed additional issues:

1) Completely templated list items currently always break up lists in Parsoid. Test case: echo -ne '*foo\n{{:User:GWicke/li|bar}}\n*baz' | node parse

2) This covers up another bug in the template encapsulation code. Template-affected lists are only marked as such because the list handler starts a new list for each templated list item. This (correctly) places the meta element we use to track template-affected content outside the 
       triggered by the template-generated list item. Once 1) is fixed, we will have to fix this up with a special rule in the encapsulation code that marks the parent list as template-affected if one of its wikitext-syntax items is template-generated. The meta element will end up between list items, so a propagation rule should be sufficient.

None of this will do much for the ease of editing. I realize that fixing up a lot of pages to use explicit bullets in the page will create a lot of work for bots, but at the same time I don't see a sane alternative that provides a good editing experience.",task_subcomment,"A deeper investigation revealed additional issues:

1) Completely templated list items currently always break up lists in Parsoid. Test case: echo -ne '*foo\n{{:User:GWicke/li|bar}}\n*baz' | node parse

2) This covers up another bug in the template encapsulation code. Template-affected lists are only marked as such because the list handler starts a new list for each templated list item. This (correctly) places the meta element we use to track template-affected content outside the 
         triggered by the template-generated list item. Once 1) is fixed, we will have to fix this up with a special rule in the encapsulation code that marks the parent list as template-affected if one of its wikitext-syntax items is template-generated. The meta element will end up between list items, so a propagation rule should be sufficient.

None of this will do much for the ease of editing. I realize that fixing up a lot of pages to use explicit bullets in the page will create a lot of work for bots, but at the same time I don't see a sane alternative that provides a good editing experience.",SOLUTION DISCUSSION
254285,Transcluded pages quasi-template eats into subsequent entry,"(In reply to comment #8)
> That said, there is a possibility that for lists, this problem is solvable by
> marking a series of adjacent list nodes as template generated -- Parsoid
> already has the mechanism of marking a forest of adjacent DOM nodes as
> template-generated instead of marking just a root-node. 

The problem is that the list is also template-affected, and needs to be marked as such. A change in transclusion output (say, from *foo to #foo) will change the list structure significantly, so it is not safe to mark the list items only.

The example page exposes a different issue though, which you mention as well: The comments between transclusions (which probably end up on their own line after expansion) break up the list in Parsoid, but don't do so in PHP (bug 52762). This is not surprising as the PHP parser strips those comments before doing anything else, but still something we could improve by not breaking up the list.

Sadly, the effect of this will be that the entire list will be template-affected.

This problem would not be there if the bullet for the list item was not templated:

* {{:Christian Delius}}
* [[Christina Rau]], geb. Delius (* 1956), deutsche Politologin

In this case we know that the first list item will always create an unordered list, no matter what the transclusion generates (ignoring unbalanced transclusions for now). Each item will be editable separately without being sucked into a big template-affected block.",task_subcomment,"(In reply to comment #8)
QUOTE
QUOTE
QUOTE
QUOTE

The problem is that the list is also template-affected, and needs to be marked as such. A change in transclusion output (say, from *foo to #foo) will change the list structure significantly, so it is not safe to mark the list items only.

The example page exposes a different issue though, which you mention as well: The comments between transclusions (which probably end up on their own line after expansion) break up the list in Parsoid, but don't do so in PHP (bug 52762). This is not surprising as the PHP parser strips those comments before doing anything else, but still something we could improve by not breaking up the list.

Sadly, the effect of this will be that the entire list will be template-affected.

This problem would not be there if the bullet for the list item was not templated:

* {{:Christian Delius}}
* [[Christina Rau]], geb. Delius (* 1956), deutsche Politologin

In this case we know that the first list item will always create an unordered list, no matter what the transclusion generates (ignoring unbalanced transclusions for now). Each item will be editable separately without being sucked into a big template-affected block.",SOLUTION DISCUSSION
254282,Transcluded pages quasi-template eats into subsequent entry,"I personally am not going to apply that metric to this page -- for example, table tags cannot be edited in VE, extension source cannot be edited in VE, and wikitext that shows up in between multi-part templates cannot be edited in VE.  I think this particular issue falls in the same category.

I do agree that the experience is sub-optimal.  But given that it does not break wikitext, I mean no disrespect to your opinion, but I disagree with you that we ought to therefore make the entire page uneditable.  As to your suggestion of providing a generic warning for uneditable pieces in VE, I'll James address that part.

But, as I noted above, at least for dab pages using list items, this problem might be solvable if we can figure out why transclusions are splitting existing lists at the transclusion point.",task_subcomment,"I personally am not going to apply that metric to this page -- for example, table tags cannot be edited in VE, extension source cannot be edited in VE, and wikitext that shows up in between multi-part templates cannot be edited in VE.  I think this particular issue falls in the same category.

I do agree that the experience is sub-optimal.  But given that it does not break wikitext, I mean no disrespect to your opinion, but I disagree with you that we ought to therefore make the entire page uneditable.  As to your suggestion of providing a generic warning for uneditable pieces in VE, I'll James address that part.

But, as I noted above, at least for dab pages using list items, this problem might be solvable if we can figure out why transclusions are splitting existing lists at the transclusion point.",SOLUTION DISCUSSION
254278,Transcluded pages quasi-template eats into subsequent entry,"Please read the bug report and reproduce. The current behaviour is sub-optimal. Perhaps its not a high priority as it doesnt break the wiki-text, but that doesn't mean it isnt contrary to user expectations.
Text on the page (in the wiki text) should be editable on the page. If the VE cant edit all the wikitext on the page, the page is not yet functional in VE, and only SE should be offered to the user (or VE should tell the user to use SE to edit those bits).",task_subcomment,"Please read the bug report and reproduce. The current behaviour is sub-optimal. Perhaps its not a high priority as it doesnt break the wiki-text, but that doesn't mean it isnt contrary to user expectations.
Text on the page (in the wiki text) should be editable on the page. If the VE cant edit all the wikitext on the page, the page is not yet functional in VE, and only SE should be offered to the user (or VE should tell the user to use SE to edit those bits).",BUG REPRODUCTION
254274,Transcluded pages quasi-template eats into subsequent entry,"That said, there is a possibility that for lists, this problem is solvable by marking a series of adjacent list nodes as template generated -- Parsoid already has the mechanism of marking a forest of adjacent DOM nodes as template-generated instead of marking just a root-node.  I suspect the reason this is not already happening is because of an (un)related list parsing bug.  Bug 49974, now merged into Bug 52762.  Once that is resolved, this problem will be fixed for the specific example pages on this page.  And as long as most of the disambiguation pages use this pattern (list items), it should be okay for them.",task_subcomment,"That said, there is a possibility that for lists, this problem is solvable by marking a series of adjacent list nodes as template generated -- Parsoid already has the mechanism of marking a forest of adjacent DOM nodes as template-generated instead of marking just a root-node.  I suspect the reason this is not already happening is because of an (un)related list parsing bug.  Bug 49974, now merged into Bug 52762.  Once that is resolved, this problem will be fixed for the specific example pages on this page.  And as long as most of the disambiguation pages use this pattern (list items), it should be okay for them.",SOLUTION DISCUSSION
254268,Transcluded pages quasi-template eats into subsequent entry,"(In reply to comment #5)
> The bug still exists. VE should handle this differently: mark the whole page
> as
> not compatible with VE if you must.

John: can you clarify what could be done here? 

As far as I can tell, there is no broken HTML, and neither is there any corruption on edit and save. The only problem is that top-level page content is sucked into transclusion content and is not editable. In the current scenario, at least some part of the page is editable in VE. How would marking the whole page not editable solve this issue?",task_subcomment,"(In reply to comment #5)
QUOTE
QUOTE
QUOTE

John: can you clarify what could be done here? 

As far as I can tell, there is no broken HTML, and neither is there any corruption on edit and save. The only problem is that top-level page content is sucked into transclusion content and is not editable. In the current scenario, at least some part of the page is editable in VE. How would marking the whole page not editable solve this issue?",SOLUTION DISCUSSION
254263,Transcluded pages quasi-template eats into subsequent entry,*** Bug 52814 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52814 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
254258,Transcluded pages quasi-template eats into subsequent entry,The bug still exists. VE should handle this differently: mark the whole page as not compatible with VE if you must.,task_subcomment,The bug still exists. VE should handle this differently: mark the whole page as not compatible with VE if you must.,BUG REPRODUCTION
254253,Transcluded pages quasi-template eats into subsequent entry,"As James indicates in https://bugzilla.wikimedia.org/show_bug.cgi?id=51119#c2, there is really not much we can do about this. The implicit 
           is started by a template, so the entire list needs to be marked as template-affected even if some items in it are not templated.

Since I don't see a good way to improve this situation in Parsoid, I'm going to close this bug as wontfix for now. Please reopen this bug if you have an idea on how this could be handled better.",task_subcomment,"As James indicates in URL there is really not much we can do about this. The implicit 
             is started by a template, so the entire list needs to be marked as template-affected even if some items in it are not templated.

Since I don't see a good way to improve this situation in Parsoid, I'm going to close this bug as wontfix for now. Please reopen this bug if you have an idea on how this could be handled better.",ACTION ON ISSUE
463290,Transcluded pages quasi-template eats into subsequent entry,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this: https://en.wikipedia.org/wiki/Howes?veaction=edit

Some impact analysis for the next set of wikis in line for VE deployment:

* dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
  - not all of those suffer from the second issue raised; sometimes they have whitespace between transclusion and the next item
  --  e.g. https://de.wikipedia.org/wiki/Kalam?veaction=edit
* frwp,hewp,nlwp: between 1&4 pages transcluding mainspace
* svwp: 250, all dab pages
* ruwp: 1616, all dab pages - i.e. 0.15% of all content pages

Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
https://ru.wikipedia.org/wiki/%D0%9B%D0%BB%D0%BE%D0%B9%D0%B4?veaction=edit
https://ru.wikipedia.org/wiki/Lloyd%E2%80%99s

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
```
select count(*)
from   templatelinks tl inner join page p on (tl.tl_from = p.page_id)
where  tl_namespace = 0
and    page_namespace = 0
and    tl_from in 
  (select cl_from from categorylinks where cl_to =  'Begriffsklärung')
;
```",task_subcomment,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this: URL

Some impact analysis for the next set of wikis in line for VE deployment:

* dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
  - not all of those suffer from the second issue raised; sometimes they have whitespace between transclusion and the next item
  --  e.g. URL
* frwp,hewp,nlwp: between 1&4 pages transcluding mainspace
* svwp: 250, all dab pages
* ruwp: 1616, all dab pages - i.e. 0.15% of all content pages

Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
URL
URL

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
``CODE``",SOLUTION DISCUSSION
463286,Transcluded pages quasi-template eats into subsequent entry,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this:
   e.g. https://en.wikipedia.org/wiki/Howes?veaction=edit

Some impact analysis for the next set of wikis in line for VE deployment:

* dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
  - not all of those suffer from the second issue raised; sometimes they have whitespace between transclusion and the next item
  --  e.g. https://de.wikipedia.org/wiki/Kalam?veaction=edit
* frwp,hewp,nlwp: between 1&4 pages transcluding mainspace
* svwp: 250, all dab pages
* ruwp: 1616, all dab pages - i.e. 0.15% of all content pages

Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
https://ru.wikipedia.org/wiki/%D0%9B%D0%BB%D0%BE%D0%B9%D0%B4?veaction=edit
https://ru.wikipedia.org/wiki/Lloyd%E2%80%99s

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
```
select count(*)
from   templatelinks tl inner join page p on (tl.tl_from = p.page_id)
where  tl_namespace = 0
and    page_namespace = 0
and    tl_from in 
  (select cl_from from categorylinks where cl_to =  'Begriffsklärung')
;
```",task_subcomment,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this:
   e.g. URL

Some impact analysis for the next set of wikis in line for VE deployment:

* dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
  - not all of those suffer from the second issue raised; sometimes they have whitespace between transclusion and the next item
  --  e.g. URL
* frwp,hewp,nlwp: between 1&4 pages transcluding mainspace
* svwp: 250, all dab pages
* ruwp: 1616, all dab pages - i.e. 0.15% of all content pages

Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
URL
URL

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
``CODE``",SOLUTION DISCUSSION
254250,Transcluded pages quasi-template eats into subsequent entry,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this:
   e.g. https://en.wikipedia.org/wiki/Howes?veaction=edit

Some impact analysis for the next set of wikis in line for VE deployment:

dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
 - not all of those suffer from the second issue raised; 
   sometimes they have whitespace between transclusion and the next item
   e.g. https://de.wikipedia.org/wiki/Kalam?veaction=edit

frwp,hewp,nlwp: between 1&4 pages transcluding mainspace

svwp: 250, all dab pages

ruwp: 1616, all dab pages - i.e. 0.15% of all content pages
  Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
https://ru.wikipedia.org/wiki/%D0%9B%D0%BB%D0%BE%D0%B9%D0%B4?veaction=edit
https://ru.wikipedia.org/wiki/Lloyd%E2%80%99s

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
select count(*)
from   templatelinks tl inner join page p on (tl.tl_from = p.page_id)
where  tl_namespace = 0
and    page_namespace = 0
and    tl_from in 
  (select cl_from from categorylinks where cl_to =  'Begriffsklärung')
;",task_subcomment,"This is not really a problem that affects enwp.  If my SQL is right, enwp has only 14 dab pages that transclude mainspace - easily a manual fixup task, esp. when some look of them look like this:
   e.g. URL

Some impact analysis for the next set of wikis in line for VE deployment:

dewp: 22226 content pages transcluding mainspace - i.e. 1.4% of all 'content pages', of which 9012 are dab pages - i.e. 0.5% of all content pages
 - not all of those suffer from the second issue raised; 
   sometimes they have whitespace between transclusion and the next item
   e.g. URL

frwp,hewp,nlwp: between 1&4 pages transcluding mainspace

svwp: 250, all dab pages

ruwp: 1616, all dab pages - i.e. 0.15% of all content pages
  Looking at a Russian example; it doesnt face the second problem raised in comment 1; the last item on this dab page is not consumed by the {{:Lloyd's}} above it.
URL
URL

ruwp uses noinclude instead of onlyinclude.

My SLQ on dewp:
select count(*)
from   templatelinks tl inner join page p on (tl.tl_from = p.page_id)
where  tl_namespace = 0
and    page_namespace = 0
and    tl_from in 
  (select cl_from from categorylinks where cl_to =  'Begriffsklärung')
;",SOLUTION DISCUSSION
254246,Transcluded pages quasi-template eats into subsequent entry,"Relevant wikitext excerpt:

| {{:Christian Delius}}
| 
| * [[Christina Rau]], geb. Delius (* 1956), deutsche Politologin

Yeah, this is because the HTML comment and 
          •  in the wikitext below the template insert themselves into the implicit 
               that the template creates (and so get marked as part of the same ""MediaWiki transclusions"" generated content block as the template by Parsoid.

I'm not sure what Parsoid could do to ""fix"" this, really. It's correct parsing of broken-by-design wikitext (which doesn't seem obvious if you're not parsing it).",task_subcomment,"Relevant wikitext excerpt:

| {{:Christian Delius}}
| 
| * [[Christina Rau]], geb. Delius (* 1956), deutsche Politologin

Yeah, this is because the HTML comment and 
            •  in the wikitext below the template insert themselves into the implicit 
                 that the template creates (and so get marked as part of the same ""MediaWiki transclusions"" generated content block as the template by Parsoid.

I'm not sure what Parsoid could do to ""fix"" this, really. It's correct parsing of broken-by-design wikitext (which doesn't seem obvious if you're not parsing it).",INVESTIGATION AND EXPLORATION
254243,Transcluded pages quasi-template eats into subsequent entry,"The cited example is
https://de.wikipedia.org/wiki/Delius?veaction=edit

The entry 'Christina Rau' is not editable, as VE believes it is part of the 'template' {{:Christian Delius}}

Possibly because the onlyinclude on
https://de.wikipedia.org/w/index.php?title=Christian_Delius&action=edit",task_subcomment,"The cited example is
URL

The entry 'Christina Rau' is not editable, as VE believes it is part of the 'template' {{:Christian Delius}}

Possibly because the onlyinclude on
URL",BUG REPRODUCTION
53103,VisualEditor: Auto-external links to image files which are broken (404/etc.) display as the filename and cannot be edited,"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",task_description,"When a raw URL with no markup (e.g. URL ) 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 URL for my sandbox testing.

This is not unlikely related to bug 51092 in some way.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
253451,VisualEditor: Auto-external links to image files which are broken (404/etc.) display as the filename and cannot be edited,"This will be entirely fixed by bug 51092 being fixed (well, theoretically if a site administrator wants to have VE but also $wgAllowExternalImages set true, it'd be a problem, but we'll have fixed this issue with a forthcoming re-write of image handling anyway before we've shipped VE as stable).

Marking as a duplicate.

*** This bug has been marked as a duplicate of bug 51092 ***",task_subcomment,"This will be entirely fixed by bug 51092 being fixed (well, theoretically if a site administrator wants to have VE but also $wgAllowExternalImages set true, it'd be a problem, but we'll have fixed this issue with a forthcoming re-write of image handling anyway before we've shipped VE as stable).

Marking as a duplicate.

*** This bug has been marked as a duplicate of bug 51092 ***",ACTION ON ISSUE
53094,Editing adds JavaScript,"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",task_description,"I just attempted to make URL with VisualEditor and got URL instead.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
252900,Editing adds JavaScript,"(In reply to comment #2)
> How would the addition be the plugin's fault? It isn't added in the normal
> edit
> box, or in any other boxes at that.

Your browser's plug-in is inserting HTML into contentEditable 
                s. Some example complaints from around the Web:

* http://wordpress.org/support/topic/appears-after-url-and-unknown-script-inserted
* http://www.joomlaportal.de/joomla-2-5-allgemeine-fragen/291114-automatische-scriptinstallation-foxlingojs.html
* http://www.bluestonedesign.de/faq/20-sonstige-fragen/376-foxlingojs-script-in-joomla-und-wordpress-beitraegen
* http://doc.eklablog.com/blog-de-texte-bizarre-topic48844
* http://forum.wpde.org/allgemeines/108364-foxlingo-script-evtl-schadsoftware-wer-kennt-es.html
* https://drupal.org/node/1871476

There is nothing sane that VisualEditor can do to stop your broken browser, except to ask you here to stop using it. (Though I'd recommend use of a global AbuseFilter to prevent this and similar corruptions of wikis' content.)

Reclosing.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE

Your browser's plug-in is inserting HTML into contentEditable 
                s. Some example complaints from around the Web:

* URL
* URL
* URL
* URL
* URL
* URL

There is nothing sane that VisualEditor can do to stop your broken browser, except to ask you here to stop using it. (Though I'd recommend use of a global AbuseFilter to prevent this and similar corruptions of wikis' content.)

Reclosing.",ACTION ON ISSUE
252894,Editing adds JavaScript,"How would the addition be the plugin's fault? It isn't added in the normal edit box, or in any other boxes at that.",task_subcomment,"How would the addition be the plugin's fault? It isn't added in the normal edit box, or in any other boxes at that.",ACTION ON ISSUE
252886,Editing adds JavaScript,"From a quick Google, this is a faulty browser plugin of some kind, FoxLingoJs.",task_subcomment,"From a quick Google, this is a faulty browser plugin of some kind, FoxLingoJs.",BUG REPRODUCTION
53077,"VisualEditor: Link inspector blown to pieces when pressing return after clicking ""Insert link"" (before the inspector has finishes opening)","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}",task_description,"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}",BUG REPRODUCTION
252015,"VisualEditor: Link inspector blown to pieces when pressing return after clicking ""Insert link"" (before the inspector has finishes opening)","

*** This bug has been marked as a duplicate of bug 49941 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 49941 ***",ACTION ON ISSUE
53072,Adding a {{cn}} template causes VisualEditor to silently add .. to the edited paragraph,"**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  issues on bugzilla

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"**Author:** CODE

**Description:**
Tried to add {{cn}} to an article, visual editor silently added NOWIKI../NOWIKI tags on saving, which had to be manually removed.

URL

Unclear if this is the same or different as other  issues on bugzilla

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
251678,Adding a {{cn}} template causes VisualEditor to silently add .. to the edited paragraph,"Closing as INVALID (this is not a bug, this is exactly expected behaviour). Please re-open if we have mis-judged.",task_subcomment,"Closing as INVALID (this is not a bug, this is exactly expected behaviour). Please re-open if we have mis-judged.",ISSUE CONTENT MANAGEMENT
251673,Adding a {{cn}} template causes VisualEditor to silently add .. to the edited paragraph,"Did you type the text ""{{cn}}"" into the editor directly? In that case this is correct behavior: we did what was needed to make the literal text ""{{cn}}"" appear.

To insert a template in VE you'll need to use the puzzle piece icon in the toolbar. Typing wikitext directly into the editor is deliberately not supported.",task_subcomment,"Did you type the text ""{{cn}}"" into the editor directly? In that case this is correct behavior: we did what was needed to make the literal text ""{{cn}}"" appear.

To insert a template in VE you'll need to use the puzzle piece icon in the toolbar. Typing wikitext directly into the editor is deliberately not supported.",SOLUTION USAGE
53066,VisualEditor: Link input field identifiers in DOM are bogus,"corrupt  identifier in DOM for Link

see screenshot

what is this ""class""?

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11753}",task_description,"corrupt  identifier in DOM for Link

see screenshot

what is this ""class""?

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11753}",BUG REPRODUCTION
251306,VisualEditor: Link input field identifiers in DOM are bogus,"It's not corrupt, it's just empty.

jQuery doesn't remove the attribute when removing the last class. In this case, we add the class to make the input ""pending"" and then remove it when the AJAX call is done.

I don't think this is a real problem - if you have code that takes a different path based on whether the class attribute is set, has a non-empty value, or has a value, I suspect the first two cases should just be folded together.",task_subcomment,"It's not corrupt, it's just empty.

jQuery doesn't remove the attribute when removing the last class. In this case, we add the class to make the input ""pending"" and then remove it when the AJAX call is done.

I don't think this is a real problem - if you have code that takes a different path based on whether the class attribute is set, has a non-empty value, or has a value, I suspect the first two cases should just be folded together.",SOLUTION DISCUSSION
53058,VisualEditor: reference editing bringing you to the wrong citation (template problem?),"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",task_description,"Reference editing on, for example, URL 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",INVESTIGATION AND EXPLORATION
250640,VisualEditor: reference editing bringing you to the wrong citation (template problem?),"Merging this with bug 50474.

*** This bug has been marked as a duplicate of bug 50474 ***",task_subcomment,"Merging this with bug 50474.

*** This bug has been marked as a duplicate of bug 50474 ***",ACTION ON ISSUE
250635,VisualEditor: reference editing bringing you to the wrong citation (template problem?),"The observation: I was trying to make this edit - http://en.wikipedia.org/w/index.php?title=Friedrich_Nietzsche&curid=10671&diff=563544089&oldid=562894275 - Opened article in VE, saw the ""as as"" was in footnote 134 ... couldn't edit there ... went up to reference 134, clicked on it to edit, and it was the wrong reference link. It actually gave me the reference that's numbered 220 (in that version) to edit!",task_subcomment,"The observation: I was trying to make this edit - URL - Opened article in VE, saw the ""as as"" was in footnote 134 ... couldn't edit there ... went up to reference 134, clicked on it to edit, and it was the wrong reference link. It actually gave me the reference that's numbered 220 (in that version) to edit!",BUG REPRODUCTION
53054,VisualEditor: duplicate links created if parts of the link are differently italicised/bolded,"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",task_description,"See URL for example; It should be [[''death'' metal]].

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
250416,VisualEditor: duplicate links created if parts of the link are differently italicised/bolded,"Merging with bug 50098.

*** This bug has been marked as a duplicate of bug 50098 ***",task_subcomment,"Merging with bug 50098.

*** This bug has been marked as a duplicate of bug 50098 ***",ACTION ON ISSUE
250413,VisualEditor: duplicate links created if parts of the link are differently italicised/bolded,"With the sole exception of plaint text followed by italic text, it seems that a separate link is created for each part of the link that has a different bold/italic status:

https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&diff=574094377&oldid=574094235
https://en.wikipedia.org/w/index.php?title=User:Thryduulf/sandbox4&diff=574094083&oldid=574093861

To reproduce:
1. Create or edit any page that has consecutive words that have different italic/bold annotation, i.e. any of
''one'' two
'''un''' deaux
''ein'' '''zwei'''
'''un''' ''dai''
'''uno''' due

2. select both words and make the selection a link (internal or external).

Expected behaviour: One link is created, e.g. [[link|''one'' two]]
Actual behaviour: Two links are created, e.g. [[link|''one''']] [[link|two]]",task_subcomment,"With the sole exception of plaint text followed by italic text, it seems that a separate link is created for each part of the link that has a different bold/italic status:

URL
URL

To reproduce:
1. Create or edit any page that has consecutive words that have different italic/bold annotation, i.e. any of
''one'' two
'''un''' deaux
''ein'' '''zwei'''
'''un''' ''dai''
'''uno''' due

2. select both words and make the selection a link (internal or external).

Expected behaviour: One link is created, e.g. [[link|''one'' two]]
Actual behaviour: Two links are created, e.g. [[link|''one''']] [[link|two]]",BUG REPRODUCTION
250409,VisualEditor: duplicate links created if parts of the link are differently italicised/bolded,"Is this still happening? 
In my sandbox just now, VE changed [[Ancient Carthage]] to [[Ancient Carthage|''Ancient'' Carthage]] as I would expect.

https://en.wikipedia.org/w/index.php?title=User%3AThryduulf%2Fsandbox2&diff=570143239&oldid=568345382",task_subcomment,"Is this still happening? 
In my sandbox just now, VE changed [[Ancient Carthage]] to [[Ancient Carthage|''Ancient'' Carthage]] as I would expect.

URL",SOLUTION USAGE
53048,VisualEditor: The transparent color that shows the template goes up to the previous element instead of the top of the template,"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}",task_description,"a screenshot with the problem

To reproduce:

1. Go to URL
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}",BUG REPRODUCTION
250127,VisualEditor: The transparent color that shows the template goes up to the previous element instead of the top of the template,"This is caused by the phantom starting from the logical position of the content, rather than the rendered position (due to the width being 100%). Merging with bug 50395.

*** This bug has been marked as a duplicate of bug 50395 ***",task_subcomment,"This is caused by the phantom starting from the logical position of the content, rather than the rendered position (due to the width being 100%). Merging with bug 50395.

*** This bug has been marked as a duplicate of bug 50395 ***",BUG REPRODUCTION
53024,VisualEditor: adding spaces?,"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",task_description,"Possibly the most vanilla dirty diff ever, if it is a dirty diff - in URL the VE has added an extra space (before ""novel"").

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
249077,VisualEditor: adding spaces?,"This seems to be bug 48570

*** This bug has been marked as a duplicate of bug 48570 ***",task_subcomment,"This seems to be bug 48570

*** This bug has been marked as a duplicate of bug 48570 ***",ACTION ON ISSUE
249070,VisualEditor: adding spaces?,"It might be worth noting that spaces keep being added each time you edit an article with this bug (some examples here: https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:%C3%89diteurVisuel/Avis#Insertion_d.27une_espace_suppl.C3.A9mentaire_.C3.A0_chaque_.C3.A9dition , it seems related to the colon), and that some of them are not even real whitespaces.",task_subcomment,"It might be worth noting that spaces keep being added each time you edit an article with this bug (some examples here: URL , it seems related to the colon), and that some of them are not even real whitespaces.",BUG REPRODUCTION
249060,VisualEditor: adding spaces?,"Other examples:

In this diff, the second whitespace was intended, but the first one wasn't:
https://fr.wikipedia.org/w/index.php?diff=94475506

In the subsequent edit, the user tried to remove the space that was inserted by VE, and not only was he not able to remove it, but VE actually added /another/ space:
https://fr.wikipedia.org/w/index.php?diff=94475570&oldid=94475506

I notice that in these 2 cases, as well as in the case reported in comment 1, there's an adjacent colon. Dunno if it's related.",task_subcomment,"Other examples:

In this diff, the second whitespace was intended, but the first one wasn't:
URL

In the subsequent edit, the user tried to remove the space that was inserted by VE, and not only was he not able to remove it, but VE actually added /another/ space:
URL

I notice that in these 2 cases, as well as in the case reported in comment 1, there's an adjacent colon. Dunno if it's related.",MOTIVATION
249053,VisualEditor: adding spaces?,Talking about spaces: https://en.wikipedia.org/w/index.php?title=Genie_%28feral_child%29&diff=564429158&oldid=564425048,task_subcomment,Talking about spaces: URL,SOLUTION DISCUSSION
249047,VisualEditor: adding spaces?,"Same thing here after ""équipes"": http://fr.wikipedia.org/w/index.php?title=Mafia_%28jeu%29&diff=94892395&oldid=91395852",task_subcomment,"Same thing here after ""équipes"": URL",BUG REPRODUCTION
53018,"VisualEditor: ""clear formatting"" does not remove links","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",task_description,"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",BUG REPRODUCTION
248445,"VisualEditor: ""clear formatting"" does not remove links","Yeah, this is a really irritating regression; merging with the other.

*** This bug has been marked as a duplicate of bug 50461 ***",task_subcomment,"Yeah, this is a really irritating regression; merging with the other.

*** This bug has been marked as a duplicate of bug 50461 ***",ACTION ON ISSUE
248439,"VisualEditor: ""clear formatting"" does not remove links","Yes, the toolbar button (""No"" symbol) gives the impression that it should remove every skerrick of formatting from the text, including links.",task_subcomment,"Yes, the toolbar button (""No"" symbol) gives the impression that it should remove every skerrick of formatting from the text, including links.",EXPECTED BEHAVIOR
53017,VisualEditor: Template dialog crushing parameters together and nowiking links,"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",task_description,"See URL and URL for how the markup for that appears.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
248399,VisualEditor: Template dialog crushing parameters together and nowiking links,"This is now fixed (and has been for some time, I believe). Sorry for the disruption.",task_subcomment,"This is now fixed (and has been for some time, I believe). Sorry for the disruption.",SOLUTION USAGE
248392,VisualEditor: Template dialog crushing parameters together and nowiking links,Ditto - https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Sir_Lothar/brudnopis2&diff=prev&oldid=37137604,task_subcomment,Ditto - URL,ACTION ON ISSUE
248384,VisualEditor: Template dialog crushing parameters together and nowiking links,"I don't think that this is just a problem with browser extensions misbehaving over links.  This edit:

https://pl.wikipedia.org/w/index.php?title=Rory_MacDonald&curid=2849478&diff=37138750&oldid=36592431

involves no links, and yet the data is still placed after a line break and smashed up against the following parameter, instead of up on the previous line where it belongs.",task_subcomment,"I don't think that this is just a problem with browser extensions misbehaving over links.  This edit:

URL

involves no links, and yet the data is still placed after a line break and smashed up against the following parameter, instead of up on the previous line where it belongs.",BUG REPRODUCTION
248376,VisualEditor: Template dialog crushing parameters together and nowiking links,"Some broken browser extension sometimes adds lots of  ... tags around items which is tracked by and edit filter. Attempting to clean these up with the VE worked well in the main text but failed in the templates changing

{{Infobox company
...
| foundation     = [[1990 in video gaming|1990]]
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )
                [[Skylanders|''Skylanders'' series]] (2011-2013)0)"">Guitar Hero|''Guitar Hero'' series]] (2007–2010) 
...
}}

Into
{{Infobox company
|1990]]
|''Guitar Hero'' series]] (2007–2010) 
...
| foundation     = [[1990 in video gaming
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )
                [[Skylanders|''Skylanders'' series]] (2011-2013) Guitar Hero
...
}}
splitting the foundation and product parameters.",task_subcomment,"Some broken browser extension sometimes adds lots of  ... tags around items which is tracked by and edit filter. Attempting to clean these up with the VE worked well in the main text but failed in the templates changing

{{Infobox company
...
| foundation     = [[1990 in video gaming|1990]]
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )
                [[Skylanders|''Skylanders'' series]] (2011-2013)0)"">Guitar Hero|''Guitar Hero'' series]] (2007–2010) 
...
}}

Into
{{Infobox company
|1990]]
|''Guitar Hero'' series]] (2007–2010) 
...
| foundation     = [[1990 in video gaming
| products       = [[Crash Bandicoot|''Crash Bandicoot'' series]] (2002-2004) (2013- )
                [[Skylanders|''Skylanders'' series]] (2011-2013) Guitar Hero
...
}}
splitting the foundation and product parameters.",SOLUTION DISCUSSION
52991,VisualEditor: Template highlight is sometimes misplaced in the reference inspector,"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",task_description,"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:

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
246993,VisualEditor: Template highlight is sometimes misplaced in the reference inspector,"

*** This bug has been marked as a duplicate of bug 50913 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50913 ***",ACTION ON ISSUE
52986,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","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",task_description,"1) Open an article such as
URL
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**:
URL",SOLUTION USAGE
246781,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon.

*** This bug has been marked as a duplicate of bug 50240 ***",task_subcomment,"This is a duplicate of bug 50240; yes, this would be a nice enhancement to get done soon.

*** This bug has been marked as a duplicate of bug 50240 ***",BUG REPRODUCTION
246779,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)",See also gerrit change 70564.,task_subcomment,See also gerrit change 70564.,SOLUTION USAGE
246776,"VisualEditor should not encourage links of little relevance (e.g. disambiguation pages, already used links, etc..)","PS: this was inspired by the commit message of
https://gerrit.wikimedia.org/r/#/c/72646/",task_subcomment,"PS: this was inspired by the commit message of
URL",SOLUTION DISCUSSION
52977,Selecting text does not work,"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",task_description,"How to reproduce:
* Go to URL
* 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",BUG REPRODUCTION
246291,Selecting text does not work,"Hey, sorry for the confusion; merging with bug 50643 which is about disabling Firefox's misleading interface.

*** This bug has been marked as a duplicate of bug 50643 ***",task_subcomment,"Hey, sorry for the confusion; merging with bug 50643 which is about disabling Firefox's misleading interface.

*** This bug has been marked as a duplicate of bug 50643 ***",ACTION ON ISSUE
246288,Selecting text does not work,Selecting text works at the page you provided but drag and drop does not work.,task_subcomment,Selecting text works at the page you provided but drag and drop does not work.,BUG REPRODUCTION
246283,Selecting text does not work,"(In reply to comment #3)
> try it on another page like
Selecting text work at the page your provided but drag and drop does not work.
----
You receive this bug's description kindly in English.
Rainer Rillke",task_subcomment,"(In reply to comment #3)
QUOTE
Selecting text work at the page your provided but drag and drop does not work.
----
You receive this bug's description kindly in English.
Rainer Rillke",BUG REPRODUCTION
246277,Selecting text does not work,"(In reply to comment #3)
I tried editing 2 pages on MediaWiki wiki so far and it did not work as I expected. If it can't deal with  tags, it must be disabled on these pages. Thank you.",task_subcomment,"(In reply to comment #3)
I tried editing 2 pages on MediaWiki wiki so far and it did not work as I expected. If it can't deal with  tags, it must be disabled on these pages. Thank you.",SOLUTION USAGE
246272,Selecting text does not work,"It seems related to the  tag, try it on another page like https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet",task_subcomment,"It seems related to the  tag, try it on another page like URL",BUG REPRODUCTION
246269,Selecting text does not work,"As selecting text is a basic operation, bumping to a major issue.",task_subcomment,"As selecting text is a basic operation, bumping to a major issue.",BUG REPRODUCTION
246265,Selecting text does not work,FF 22,task_subcomment,FF 22,ACTION ON ISSUE
52975,Please turn off VisualEditor as long as it doesn't work,"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",task_description,"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",ISSUE CONTENT MANAGEMENT
246148,Please turn off VisualEditor as long as it doesn't work,"> especially as you are not forced to use it.
If a button (""Edit"") that previously did something else, now shows VE, it is ""forcing"" IMHO.

I think VE will be a great tool but as with UploasWizard please understand the community is not a playground.",task_subcomment,"QUOTE
If a button (""Edit"") that previously did something else, now shows VE, it is ""forcing"" IMHO.

I think VE will be a great tool but as with UploasWizard please understand the community is not a playground.",SOLUTION USAGE
246143,Please turn off VisualEditor as long as it doesn't work,"(In reply to comment #0)
> There are so many things that do not work

I cannot elaborate on the deployment schedule here, but I'm pretty sure that it's been explained on https://www.mediawiki.org/wiki/VisualEditor/Feedback recently, as you're not the only person with that impression. :)

I suggest to test the software better before deploying.

See above - testing has taken place for months.

There are no plans to turn VE off currently, especially as you are not forced to use it.",task_subcomment,"(In reply to comment #0)
QUOTE

I cannot elaborate on the deployment schedule here, but I'm pretty sure that it's been explained on URL recently, as you're not the only person with that impression. :)

I suggest to test the software better before deploying.

See above - testing has taken place for months.

There are no plans to turn VE off currently, especially as you are not forced to use it.",ACTION ON ISSUE
52974,Redlinks show up as bluelinks in VisualEditor mode,"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",task_description,"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:

URL

This may be a Parsoid issue?

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
246102,Redlinks show up as bluelinks in VisualEditor mode,"

*** This bug has been marked as a duplicate of bug 37901 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 37901 ***",ACTION ON ISSUE
52946,VisualEditor: line endings are not preserved when copying from a text file,"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",task_description,"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:
URL

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",BUG REPRODUCTION
244363,VisualEditor: line endings are not preserved when copying from a text file,"This should be fixed up by the fixing of bug 33105.

*** This bug has been marked as a duplicate of bug 33105 ***",task_subcomment,"This should be fixed up by the fixing of bug 33105.

*** This bug has been marked as a duplicate of bug 33105 ***",ACTION ON ISSUE
52915,context specific editor for templates?,"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",task_description,"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",SOLUTION DISCUSSION
242508,context specific editor for templates?,"This is a WONTFIX; VisualEditor is not specific to the English Wikipedia, and it is neither appropriate nor sane to create specific dialogs for each of the thousands of templates on hundreds of wikis.",task_subcomment,"This is a WONTFIX; VisualEditor is not specific to the English Wikipedia, and it is neither appropriate nor sane to create specific dialogs for each of the thousands of templates on hundreds of wikis.",SOLUTION USAGE
52909,VisualEditor: Template editor turns links into [[link|name]] in CE,"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}",task_description,"screenshot of CE after transclusion editor

URL

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}",BUG REPRODUCTION
242159,VisualEditor: Template editor turns links into [[link|name]] in CE,"

*** This bug has been marked as a duplicate of bug 50801 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50801 ***",ACTION ON ISSUE
52907,VisualEditor: The anchor for the template editor can easily become invisible,"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",task_description,"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",BUG REPRODUCTION
242091,VisualEditor: The anchor for the template editor can easily become invisible,"@Chris, yes, they are the same.

*** This bug has been marked as a duplicate of bug 49922 ***",task_subcomment,"SCREEN_NAME, yes, they are the same.

*** This bug has been marked as a duplicate of bug 49922 ***",ACTION ON ISSUE
242087,VisualEditor: The anchor for the template editor can easily become invisible,Is this the same as bug 49922?,task_subcomment,Is this the same as bug 49922?,BUG REPRODUCTION
52903,VisualEditor: Save dialog behaves as partial modal,"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",task_description,"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",BUG REPRODUCTION
241906,VisualEditor: Save dialog behaves as partial modal,"This is an artefact of not being a ""proper"" dialog, which is bug 48566 - we hope to fix that in the next week or so. Sorry for the delay in triaging.

*** This bug has been marked as a duplicate of bug 48566 ***",task_subcomment,"This is an artefact of not being a ""proper"" dialog, which is bug 48566 - we hope to fix that in the next week or so. Sorry for the delay in triaging.

*** This bug has been marked as a duplicate of bug 48566 ***",ACTION ON ISSUE
241901,VisualEditor: Save dialog behaves as partial modal,"Oh, and you can select and copy and paste text from the disabled edit surface, when the save dialog is open.",task_subcomment,"Oh, and you can select and copy and paste text from the disabled edit surface, when the save dialog is open.",SOLUTION USAGE
52835,Nested s considered harmful,"Sometimes Parsoid will wrap a  around an existing ; 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",task_description,"Sometimes Parsoid will wrap a  around an existing ; this is generally a bad idea, even if we have dirtied the reference in VisualEditor. :-)

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
237831,Nested s considered harmful,*** Bug 50724 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50724 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
237825,Nested s considered harmful,"Change 72971 merged by jenkins-bot:
Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params

https://gerrit.wikimedia.org/r/72971",task_subcomment,"Change 72971 merged by jenkins-bot:
Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params

GERRIT_URL",ACTION ON ISSUE
237819,Nested s considered harmful,"Change 72971 had a related patch set uploaded by Subramanya Sastry:
Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params

https://gerrit.wikimedia.org/r/72971",task_subcomment,"Change 72971 had a related patch set uploaded by Subramanya Sastry:
Try #2: (Bug 50835) Dont nowiki escape already escaped tpl params

GERRIT_URL",ACTION ON ISSUE
237815,Nested s considered harmful,"Change 72230 merged by jenkins-bot:
(Bug 50835) Dont nowiki escape already escaped template params

https://gerrit.wikimedia.org/r/72230",task_subcomment,"Change 72230 merged by jenkins-bot:
(Bug 50835) Dont nowiki escape already escaped template params

GERRIT_URL",ACTION ON ISSUE
237811,Nested s considered harmful,"Change 72230 had a related patch set uploaded by Subramanya Sastry:
(Bug 50835) Dont nowiki escape already escaped template params

https://gerrit.wikimedia.org/r/72230",task_subcomment,"Change 72230 had a related patch set uploaded by Subramanya Sastry:
(Bug 50835) Dont nowiki escape already escaped template params

GERRIT_URL",ACTION ON ISSUE
52828,VisualEditor: edits fail on hitting the abuse filter (with a cryptic error message),"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",task_description,"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",BUG REPRODUCTION
237369,VisualEditor: edits fail on hitting the abuse filter (with a cryptic error message),"

*** This bug has been marked as a duplicate of bug 50472 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50472 ***",ACTION ON ISSUE
52817,Keyboard shortcut for editing source,"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",task_description,"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",SOLUTION USAGE
236795,Keyboard shortcut for editing source,"Sorry about this; we fixed this just a few hours ago. Merging with the other report.

*** This bug has been marked as a duplicate of bug 50725 ***",task_subcomment,"Sorry about this; we fixed this just a few hours ago. Merging with the other report.

*** This bug has been marked as a duplicate of bug 50725 ***",ACTION ON ISSUE
52797,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"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",task_description,"Try removing the whitespace at the top of URL and see what happens.

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
235665,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"http://en.wikipedia.org/w/index.php?title=Burr%E2%80%93Hamilton_duel&oldid=561095260&veaction=edit shows the whitespace, and it also seems to be possible to delete a line there by focusing it and pressing 'delete'. Newlines that don't produce a paragraph are also preserved in HTML, but are not editable in wikitext.

See the source of http://parsoid.wmflabs.org/en/Burr%E2%80%93Hamilton_duel?oldid=561095260, in which the first paragraph after the infobox starts with ""

                "".

Closing as worksforme. Please open a bug against VE if you have trouble with focusing or deleting the 
                .",task_subcomment,"URL shows the whitespace, and it also seems to be possible to delete a line there by focusing it and pressing 'delete'. Newlines that don't produce a paragraph are also preserved in HTML, but are not editable in wikitext.

See the source of URL in which the first paragraph after the infobox starts with ""

                "".

Closing as worksforme. Please open a bug against VE if you have trouble with focusing or deleting the 
                .",ACTION ON ISSUE
235659,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"So, to understand this bug - this is about where is some (mistaken/wrong) wikitext with an extra new line in front of a block template that gets swallowed by Parsoid into the template that follows it (but can't be removed from there as Parsoid quietly hides that)?

(Note that the second extra whitespace is a normal 
                 and so shown in VisualEditor as a ""↵"" and can be removed in-line.)",task_subcomment,"So, to understand this bug - this is about where is some (mistaken/wrong) wikitext with an extra new line in front of a block template that gets swallowed by Parsoid into the template that follows it (but can't be removed from there as Parsoid quietly hides that)?

(Note that the second extra whitespace is a normal 
                 and so shown in VisualEditor as a ""↵"" and can be removed in-line.)",BUG REPRODUCTION
235651,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"Permanent link to the relevant page revision:

http://en.wikipedia.org/w/index.php?title=Burr%E2%80%93Hamilton_duel&oldid=561095260",task_subcomment,"Permanent link to the relevant page revision:

URL",ISSUE CONTENT MANAGEMENT
235644,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"This is NOT a duplicate of 47790

This bug is about whitespace in the SOURCE, that is not editable in the VE. Where 47790 deals about whitespace in VE that is not in the source.

If you look at https://en.wikipedia.org/wiki/Burr–Hamilton_duel you will see that the first line is slightly below the infobox. In VE mode, https://en.wikipedia.org/wiki/Burr–Hamilton_duel?veaction=edit they look to be at the same height. The linebreaks at the top of the source seem to have been 'compressed' and are ignored in VE, while they do have effect in render mode.",task_subcomment,"This is NOT a duplicate of 47790

This bug is about whitespace in the SOURCE, that is not editable in the VE. Where 47790 deals about whitespace in VE that is not in the source.

If you look at URL you will see that the first line is slightly below the infobox. In VE mode, URL they look to be at the same height. The linebreaks at the top of the source seem to have been 'compressed' and are ignored in VE, while they do have effect in render mode.",BUG REPRODUCTION
235635,Whitespace immediately before a template at the start of the page is swallowed and so unremoveable,"

*** This bug has been marked as a duplicate of bug 47790 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 47790 ***",ACTION ON ISSUE
52766,VisualEditor: VE's determination of image size should hook into user preferences,"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",task_description,"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",BUG REPRODUCTION
233785,VisualEditor: VE's determination of image size should hook into user preferences,Related to bug 47804 too.,task_subcomment,Related to bug 47804 too.,TASK PROGRESS
233780,VisualEditor: VE's determination of image size should hook into user preferences,"

*** This bug has been marked as a duplicate of bug 50379 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50379 ***",ACTION ON ISSUE
52753,VisualEditor: edit conflict handling,"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",task_description,"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",SOLUTION DISCUSSION
233036,VisualEditor: edit conflict handling,"(In reply to comment #0)
> 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?

What do you mean, 'plan'? Have you not encountered one yet? It works very simply: on saving, you get a message like ""Sorry, the page couldn't be saved because of an edit conflict. Click here to resolve manually"" and then takes you to the normal wikitext edit conflict page, with the wikitext of your new version below and the new current version above, as always.

It's been this way for months. There are enough bugs filed without adding ones. :-)",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE

What do you mean, 'plan'? Have you not encountered one yet? It works very simply: on saving, you get a message like ""Sorry, the page couldn't be saved because of an edit conflict. Click here to resolve manually"" and then takes you to the normal wikitext edit conflict page, with the wikitext of your new version below and the new current version above, as always.

It's been this way for months. There are enough bugs filed without adding ones. :-)",SOLUTION USAGE
52744,"VisualEditor: Once a user has inserted a new transclusion, offer to add another","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",task_description,"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",SOLUTION DISCUSSION
232406,"VisualEditor: Once a user has inserted a new transclusion, offer to add another","Re-worded the summary; I don't think that this is a route we want to go, so marking as a WONTFIX.",task_subcomment,"Re-worded the summary; I don't think that this is a route we want to go, so marking as a WONTFIX.",ACTION ON ISSUE
232400,"VisualEditor: Once a user has inserted a new transclusion, offer to add another","Maggie: Feel free to drop ""Enhancement request:"" from the report summary and to set severity to ""enhancement"" instead. Thanks. :)",task_subcomment,"Maggie: Feel free to drop ""Enhancement request:"" from the report summary and to set severity to ""enhancement"" instead. Thanks. :)",ACTION ON ISSUE
52738,VisualEditor: Template inspector's parameter display causes smushing,"See https://en.wikipedia.org/wiki/File:VisualEditor_-_Cite_template_layout_issue_%28TemplateData%29.png - Firefox 22, Monobook.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See URL - Firefox 22, Monobook.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
232107,VisualEditor: Template inspector's parameter display causes smushing,"

%%%*** This bug has been marked as a duplicate of bug 50728 ***%%%",task_subcomment,"

%%%*** This bug has been marked as a duplicate of bug 50728 ***%%%",ACTION ON ISSUE
52737,VisualEditor: not showing new categories on reload,"If you add categories to a page and save, the newly-loaded version does not include the new additions.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"If you add categories to a page and save, the newly-loaded version does not include the new additions.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
232077,VisualEditor: not showing new categories on reload,"Yeah, this would be a good one to fix; merging with duplicate.

*** This bug has been marked as a duplicate of bug 48560 ***",task_subcomment,"Yeah, this would be a good one to fix; merging with duplicate.

*** This bug has been marked as a duplicate of bug 48560 ***",ACTION ON ISSUE
232073,VisualEditor: not showing new categories on reload,"An additional note about this on English Wikipedia, with the sensible suggestion that editors are likely to think they have done something wrong when they save the page and their changes do not appear to have worked.",task_subcomment,"An additional note about this on English Wikipedia, with the sensible suggestion that editors are likely to think they have done something wrong when they save the page and their changes do not appear to have worked.",SOLUTION USAGE
52724, added to existing  content,"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  tags around existing  content (in this case the ""|"" symbol in the title of a cited website) inside a template inside a reference.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"This edit:

URL

is an example of a dirty diff where VisualEditor/Parsoid appears to have wrapped  tags around existing  content (in this case the ""|"" symbol in the title of a cited website) inside a template inside a reference.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
231259, added to existing  content,"

*** This bug has been marked as a duplicate of bug 50835 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50835 ***",ACTION ON ISSUE
231256, added to existing  content,"Other example:
http://en.wikipedia.org/w/index.php?title=Beximco&diff=562685500&oldid=562676888",task_subcomment,"Other example:
URL",ACTION ON ISSUE
52709,VisualEditor: alt text?,"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",task_description,"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",SOLUTION DISCUSSION
255304,VisualEditor: alt text?,"

*** This bug has been marked as a duplicate of bug 38129 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 38129 ***",ACTION ON ISSUE
52684,Template auto-filled with wikitext on edit,"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",task_description,"This came from the VisualEditor feedback page in Hebrew. I couldn't replicate, but the problem is evident in this diff:

URL

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",BUG REPRODUCTION
253910,Template auto-filled with wikitext on edit,"After talking to gwicke, this seems to be a temporary bug either related to some caching problem or an issue that was resolved, since it cannot be replicated and a lot of other updates were done that fixed related problems.

Closed as likely fixed.",task_subcomment,"After talking to gwicke, this seems to be a temporary bug either related to some caching problem or an issue that was resolved, since it cannot be replicated and a lot of other updates were done that fixed related problems.

Closed as likely fixed.",ISSUE CONTENT MANAGEMENT
253904,Template auto-filled with wikitext on edit,"I couldnt reproduce it on
https://he.wikipedia.org/wiki/User:John_Vandenberg/test

I cant find any bug for visualeditor dumping in a subst:ed copy of a template.  Very strange.",task_subcomment,"I couldnt reproduce it on
URL

I cant find any bug for visualeditor dumping in a subst:ed copy of a template.  Very strange.",BUG REPRODUCTION
52675,VisualEditor: Inherited category becomes explicitly invoked,"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",task_description,"This null edit to an article (URL made the category hidden inside of a template in use on the page (template in question: URL visible in the editor. It should not be visible.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
253429,VisualEditor: Inherited category becomes explicitly invoked,This was a bug in DM/Parsoid interaction that we fixed months ago; apologies for the slowness of updating.,task_subcomment,This was a bug in DM/Parsoid interaction that we fixed months ago; apologies for the slowness of updating.,BUG REPRODUCTION
253424,VisualEditor: Inherited category becomes explicitly invoked,Another example: https://fr.wikipedia.org/w/index.php?diff=94601807,task_subcomment,Another example: URL,SOLUTION USAGE
52653,Section 0 (lede) editing does not offer VisualEditor,"**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",task_description,"**Author:** CODE

**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",SOLUTION DISCUSSION
252191,Section 0 (lede) editing does not offer VisualEditor,"ve.init.mw.ViewPageTarget.prototype.setupSectionEditLinks in /modules/ve/init/mw/targets/ve.init.mw.ViewPageTarget.js in mediawiki/extensions/VisualEditor.

(It's painful to look at.)",task_subcomment,"ve.init.mw.ViewPageTarget.prototype.setupSectionEditLinks in /modules/ve/init/mw/targets/ve.init.mw.ViewPageTarget.js in mediawiki/extensions/VisualEditor.

(It's painful to look at.)",BUG REPRODUCTION
252185,Section 0 (lede) editing does not offer VisualEditor,I recall the pertinent gerrit revision as being https://gerrit.wikimedia.org/r/#/c/69984/ which should give some pointers.,task_subcomment,I recall the pertinent gerrit revision as being URL which should give some pointers.,SOLUTION DISCUSSION
252179,Section 0 (lede) editing does not offer VisualEditor,Can someone point me to the code that is building the VE edit section links ?,task_subcomment,Can someone point me to the code that is building the VE edit section links ?,TASK PROGRESS
252175,Section 0 (lede) editing does not offer VisualEditor,"**wikipedia** wrote:

Forwarded to:

  http://en.wikipedia.org/wiki/User_talk:TheDJ#edittop.js:_VisualEditor",task_subcomment,"**wikipedia** wrote:

Forwarded to:

  URL",ACTION ON ISSUE
252170,Section 0 (lede) editing does not offer VisualEditor,"The gadgets are maintained by volunteer developers (in this case, TheDJ). It's the responsibility of gadget authors to ensure compatibility with MediaWiki, not the responsibility of MediaWiki developers to ensure compatibility with gadgets. We have ~700 projects, many of which will have their own gadgets; ensuring everything we deploy is always compatible with every one of them is to tie us into knots.",task_subcomment,"The gadgets are maintained by volunteer developers (in this case, TheDJ). It's the responsibility of gadget authors to ensure compatibility with MediaWiki, not the responsibility of MediaWiki developers to ensure compatibility with gadgets. We have ~700 projects, many of which will have their own gadgets; ensuring everything we deploy is always compatible with every one of them is to tie us into knots.",SOLUTION DISCUSSION
252164,Section 0 (lede) editing does not offer VisualEditor,"**wikipedia** wrote:

As of 2013-07-03 11:42 BST, there were 22,009 accounts with gadgets-edittop enabled.",task_subcomment,"**wikipedia** wrote:

As of 2013-07-03 11:42 BST, there were 22,009 accounts with gadgets-edittop enabled.",SOLUTION DISCUSSION
52651,VisualEditor: image resizing causing implosion,"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",task_description,"See URL - it only seems to appear if you have previously resized a different image.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
252074,VisualEditor: image resizing causing implosion,"[17:29]  Could anyone mark bug 50651 as resolved? I think some new rollout fixed the issue since it no longer occurs (Ironholds reported it for me, so i cannot edit its status).
[17:30]  Resolved fixed?
[17:30]  !b 50651
[17:30]  https://bugzilla.wikimedia.org/50651
[17:30]  Yes, confirmed that the problem no longer occurs.
[17:30]  Kk",task_subcomment,"[17:29]  Could anyone mark bug 50651 as resolved? I think some new rollout fixed the issue since it no longer occurs (Ironholds reported it for me, so i cannot edit its status).
[17:30]  Resolved fixed?
[17:30]  !b 50651
[17:30]  URL
[17:30]  Yes, confirmed that the problem no longer occurs.
[17:30]  Kk",ACTION ON ISSUE
52642,Unify post-edit notifications on Wikimedia wikis,"There are currently two similar, but distinct post-edit notifications on some Wikimedia wikis. I'll attach screenshots from  momentarily.

--------------------------
**Version**: wmf-deployment
**Severity**: normal",task_description,"There are currently two similar, but distinct post-edit notifications on some Wikimedia wikis. I'll attach screenshots from  @vssun: Any specific browser? Can't reproduce it in Chrome.

I could able to reproduce with Chrome (Version 27.0.1453.116 m)/windows 7",task_subcomment,"(In reply to comment #1)
QUOTE

I could able to reproduce with Chrome (Version 27.0.1453.116 m)/windows 7",BUG REPRODUCTION
246954,VisualEditor: Bad typing/backspacing behaviour for Malayalam,"The bug 50507 is very much related to this. There, the reporter says that the characters ്, െ etc are not allowed to type.

Here the case is different but the characters are same. Characters, ി, ് and േ  (the vowel symbols of malayalam, which are joined together with preceeding consonants) are disappearing when pressing the backspace.",task_subcomment,"The bug 50507 is very much related to this. There, the reporter says that the characters ്, െ etc are not allowed to type.

Here the case is different but the characters are same. Characters, ി, ് and േ  (the vowel symbols of malayalam, which are joined together with preceeding consonants) are disappearing when pressing the backspace.",BUG REPRODUCTION
246948,VisualEditor: Bad typing/backspacing behaviour for Malayalam,Browser was Firefox 22.,task_subcomment,Browser was Firefox 22.,BUG REPRODUCTION
246944,VisualEditor: Bad typing/backspacing behaviour for Malayalam,@vssun: Any specific browser? Can't reproduce it in Chrome.,task_subcomment,SCREEN_NAME: Any specific browser? Can't reproduce it in Chrome.,BUG REPRODUCTION
52555,"VisualEditor: ""old version"" warning shows when opening VE after a VE edit","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",task_description,"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",BUG REPRODUCTION
246464,"VisualEditor: ""old version"" warning shows when opening VE after a VE edit","Yeah, really sorry about this - this is bug 50441. Very high priority in getting this fixed.

*** This bug has been marked as a duplicate of bug 50441 ***",task_subcomment,"Yeah, really sorry about this - this is bug 50441. Very high priority in getting this fixed.

*** This bug has been marked as a duplicate of bug 50441 ***",ACTION ON ISSUE
52554,VisualEditor: Likely round-trip failure involving categories and transclusion content on [[Michala Petri]],"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",task_description,"See URL

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:

URL

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
246423,VisualEditor: Likely round-trip failure involving categories and transclusion content on [[Michala Petri]],"

*** This bug has been marked as a duplicate of bug 50120 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50120 ***",ACTION ON ISSUE
246417,VisualEditor: Likely round-trip failure involving categories and transclusion content on [[Michala Petri]],"Same issue:
https://en.wikipedia.org/w/index.php?title=Richard_Mouw&curid=1175244&diff=562498507&oldid=562498198",task_subcomment,"Same issue:
URL",BUG REPRODUCTION
52553,"VisualEditor: Dialogs layer under the toolbar, hide close button","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",task_description,"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",BUG REPRODUCTION
246370,"VisualEditor: Dialogs layer under the toolbar, hide close button",This was fixed earlier this month as part of the general clean up of positioning; sorry for the slow response.,task_subcomment,This was fixed earlier this month as part of the general clean up of positioning; sorry for the slow response.,SOLUTION USAGE
52550,VisualEditor: Likely ref / transclusion round-trip failure,"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",task_description,"This edit was flagged by VE as DOM-differing, and looks like a dirty ref/transclusion:

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
246212,VisualEditor: Likely ref / transclusion round-trip failure,Fixed in Roan's DOM dirtying fixes drive in July.,task_subcomment,Fixed in Roan's DOM dirtying fixes drive in July.,SOLUTION USAGE
246207,VisualEditor: Likely ref / transclusion round-trip failure,"(In reply to comment #1)
> Only difference is the removal of two spaces after equals signs.

In which part of the DOM is this change? An attribute value?",task_subcomment,"(In reply to comment #1)
QUOTE

In which part of the DOM is this change? An attribute value?",TASK PROGRESS
246203,VisualEditor: Likely ref / transclusion round-trip failure,Only difference is the removal of two spaces after equals signs.,task_subcomment,Only difference is the removal of two spaces after equals signs.,SOLUTION DISCUSSION
52538,VisualEditor: Feedback form moves and jerks the screen around,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
245261,VisualEditor: Feedback form moves and jerks the screen around,*** Bug 50533 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50533 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
245253,VisualEditor: Feedback form moves and jerks the screen around,*** Bug 50602 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50602 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
245246,VisualEditor: Feedback form moves and jerks the screen around,Sorry about this bug; we've fixed this and just deployed it live.,task_subcomment,Sorry about this bug; we've fixed this and just deployed it live.,SOLUTION USAGE
245240,VisualEditor: Feedback form moves and jerks the screen around,"Change 71844 merged by jenkins-bot:
Listen to keypress in ve.ce.surface.$ rather than window

https://gerrit.wikimedia.org/r/71844",task_subcomment,"Change 71844 merged by jenkins-bot:
Listen to keypress in ve.ce.surface.$ rather than window

GERRIT_URL",ACTION ON ISSUE
245234,VisualEditor: Feedback form moves and jerks the screen around,"Change 71844 had a related patch set uploaded by Robmoen:
Listen to keypress in ve.ce.surface.$ rather than window.

https://gerrit.wikimedia.org/r/71844",task_subcomment,"Change 71844 had a related patch set uploaded by Robmoen:
Listen to keypress in ve.ce.surface.$ rather than window.

GERRIT_URL",SOLUTION USAGE
245227,VisualEditor: Feedback form moves and jerks the screen around,"This has also been reported on Firefox 22/Windows 7, and by a third user who hasn't specified browser/OS.",task_subcomment,"This has also been reported on Firefox 22/Windows 7, and by a third user who hasn't specified browser/OS.",BUG REPRODUCTION
245220,VisualEditor: Feedback form moves and jerks the screen around,This sounds really unhelpful; sorry about this.,task_subcomment,This sounds really unhelpful; sorry about this.,SOCIAL CONVERSATION
52529,IME selector appears when the VisualEditor headings style selector is clicked,"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  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",task_description,"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  element hiding there to capture click events (according to Roan).

URL may be able to fix it (though some modifications may be needed).

--------------------------
**Version**: unspecified
**Severity**: normal
**Whiteboard**: ve",BUG REPRODUCTION
244730,IME selector appears when the VisualEditor headings style selector is clicked,"Change 72356 merged by jenkins-bot:
Remove unnecessary ULS IME selector from VE headings menu

https://gerrit.wikimedia.org/r/72356",task_subcomment,"Change 72356 merged by jenkins-bot:
Remove unnecessary ULS IME selector from VE headings menu

GERRIT_URL",ACTION ON ISSUE
244725,IME selector appears when the VisualEditor headings style selector is clicked,"Change 72356 had a related patch set uploaded by Amire80:
Remove unnecessary ULS IME selector from VE headings menu

https://gerrit.wikimedia.org/r/72356",task_subcomment,"Change 72356 had a related patch set uploaded by Amire80:
Remove unnecessary ULS IME selector from VE headings menu

GERRIT_URL",ACTION ON ISSUE
244723,IME selector appears when the VisualEditor headings style selector is clicked,"I tested, and my assumption is correct: If https://gerrit.wikimedia.org/r/#/c/68339/ is merged, then this bug can be fixed by adding:

$wgULSNoImeSelectors[] = 'ul.ve-ui-menuWidget input';",task_subcomment,"I tested, and my assumption is correct: If URL is merged, then this bug can be fixed by adding:

$wgULSNoImeSelectors[] = 'ul.ve-ui-menuWidget input';",SOLUTION DISCUSSION
52527,Tagging articles using old markup on VE,"I note that if an editor uses old markup in VE (like [[link]]), it gets enclosed in  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",task_description,"I note that if an editor uses old markup in VE (like [[link]]), it gets enclosed in  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**:
URL",SOLUTION DISCUSSION
244645,Tagging articles using old markup on VE,"**nykevin.norris** wrote:

Removing self from CC.  Tired of spam.  Bug is dead, people.",task_subcomment,"**nykevin.norris** wrote:

Removing self from CC.  Tired of spam.  Bug is dead, people.",ACTION ON ISSUE
244639,Tagging articles using old markup on VE,"**kwwilliams** wrote:

(In reply to comment #20)
> (In reply to comment #18)
> kwwilliams: Unrelated to agreeing or disagreeing with others, could you
> please
> assume that people mean well instead of calling names, to keep Bugzilla a
> friendly place? 

I haven't called anyone names. I don't plan on starting to, either. If you can suggest a friendlier wording to describe a conscious decision not to fix a bug and requiring other people to deal with the consequences of the bug every day forever instead, I'm willing to listen to suggestions.",task_subcomment,"**kwwilliams** wrote:

(In reply to comment #20)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

I haven't called anyone names. I don't plan on starting to, either. If you can suggest a friendlier wording to describe a conscious decision not to fix a bug and requiring other people to deal with the consequences of the bug every day forever instead, I'm willing to listen to suggestions.",ACTION ON ISSUE
244635,Tagging articles using old markup on VE,"(In reply to comment #18)
kwwilliams: Unrelated to agreeing or disagreeing with others, could you please assume that people mean well instead of calling names, to keep Bugzilla a friendly place? High-level debates on general development priorities are better placed on https://en.wikipedia.org/wiki/Wikipedia:VE/F instead of a bug report which is only meant to be about a *specific* problem *in the code*. Thanks!",task_subcomment,"(In reply to comment #18)
kwwilliams: Unrelated to agreeing or disagreeing with others, could you please assume that people mean well instead of calling names, to keep Bugzilla a friendly place? High-level debates on general development priorities are better placed on URL instead of a bug report which is only meant to be about a *specific* problem *in the code*. Thanks!",ACTION ON ISSUE
244628,Tagging articles using old markup on VE,"**kwwilliams** wrote:

Closely related problems, Kevin Norris: if they would *fix* 49686, this one would go away. This one can't really be fixed because the base condition that causes it should be prevented, not reported.",task_subcomment,"**kwwilliams** wrote:

Closely related problems, Kevin Norris: if they would *fix* 49686, this one would go away. This one can't really be fixed because the base condition that causes it should be prevented, not reported.",SOLUTION DISCUSSION
244623,Tagging articles using old markup on VE,"**nykevin.norris** wrote:

(In reply to comment #17)
> Instead, James Forrester and Erik Moller have decreed that the bug not be
> fixed, and that volunteers should eagerly flock to monitoring the output of
> an
> edit filter that detects each and every time this happens to that these
> volunteers can fix it. That's repulsive. That's a level of disregard for the
> volunteers that work on this project that is breathtaking. It's the *reason*
> that the VE team can fix dozens of bugs each hour and the Wikipedia community
> still complains that they are non-responsive.

That is bug 49686, not this one.  Why are we discussing it here?",task_subcomment,"**nykevin.norris** wrote:

(In reply to comment #17)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That is bug 49686, not this one.  Why are we discussing it here?",ACTION ON ISSUE
244618,Tagging articles using old markup on VE,"**kwwilliams** wrote:

(In reply to comment #15)
> Chris, could you add a link to that comment. Im interested in why the nowiki
> edit filter isnt sufficient.

It isn't sufficient because it disappoints the first human involved, this hypothetical new editor that is so confused by all of our existing material that he's errantly typing wikitext into a source window. VE could *help* him, but instead it pops a warning. The warning obviously isn't working, because we see saves of this material happening constantly. He goes ahead and saves it anyway, and he's bewildered and confused: he did just what the little cheat sheet he got from a friend told him to do, and it didn't work.

It's insufficient because it requires a second human being to then review the change, figure out what it was that the first human was actually attempting, and then correct it if he can. 

It's insufficient because it's in support of a use-case that doesn't exist: there's no reason to put something like [[New York City|the Big Apple]] into articles. If there *were*, it's coming from an editor that is quite skilled enough to go into the source editor. If we need to support putting such things in using the visual editor, a workflow can be designed with a ""nowiki"" button to do it intentionally.

Instead, James Forrester and Erik Moller have decreed that the bug not be fixed, and that volunteers should eagerly flock to monitoring the output of an edit filter that detects each and every time this happens to that these volunteers can fix it. That's repulsive. That's a level of disregard for the volunteers that work on this project that is breathtaking. It's the *reason* that the VE team can fix dozens of bugs each hour and the Wikipedia community still complains that they are non-responsive.",task_subcomment,"**kwwilliams** wrote:

(In reply to comment #15)
QUOTE
QUOTE

It isn't sufficient because it disappoints the first human involved, this hypothetical new editor that is so confused by all of our existing material that he's errantly typing wikitext into a source window. VE could *help* him, but instead it pops a warning. The warning obviously isn't working, because we see saves of this material happening constantly. He goes ahead and saves it anyway, and he's bewildered and confused: he did just what the little cheat sheet he got from a friend told him to do, and it didn't work.

It's insufficient because it requires a second human being to then review the change, figure out what it was that the first human was actually attempting, and then correct it if he can. 

It's insufficient because it's in support of a use-case that doesn't exist: there's no reason to put something like [[New York City|the Big Apple]] into articles. If there *were*, it's coming from an editor that is quite skilled enough to go into the source editor. If we need to support putting such things in using the visual editor, a workflow can be designed with a ""nowiki"" button to do it intentionally.

Instead, James Forrester and Erik Moller have decreed that the bug not be fixed, and that volunteers should eagerly flock to monitoring the output of an edit filter that detects each and every time this happens to that these volunteers can fix it. That's repulsive. That's a level of disregard for the volunteers that work on this project that is breathtaking. It's the *reason* that the VE team can fix dozens of bugs each hour and the Wikipedia community still complains that they are non-responsive.",SOLUTION DISCUSSION
244614,Tagging articles using old markup on VE,"(In reply to comment #15)
> Chris, could you add a link to that comment. 
It's the second comment by VQuakr at https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=566546550#WONTFIX_on_nowiki.27s (that's a permalink to the present version of the page but the discussion may not have concluded yet).",task_subcomment,"(In reply to comment #15)
QUOTE
It's the second comment by VQuakr at URL (that's a permalink to the present version of the page but the discussion may not have concluded yet).",ACTION ON ISSUE
244610,Tagging articles using old markup on VE,"Chris, could you add a link to that comment. Im interested in why the nowiki edit filter isnt sufficient.
Preventing the VE nowiki edit is a bit rude, and is sticky tape of the problem with the VE causing these nowikis. In VE, the user cant _see_ the nowiki causing problem all the time. E.g. A space at the beginning of the line isnt obviously the cause of the nowiki. unless VE explicitly tells them where the nowiki is happening, how can we expect the newbie to figure it out.",task_subcomment,"Chris, could you add a link to that comment. Im interested in why the nowiki edit filter isnt sufficient.
Preventing the VE nowiki edit is a bit rude, and is sticky tape of the problem with the VE causing these nowikis. In VE, the user cant _see_ the nowiki causing problem all the time. E.g. A space at the beginning of the line isnt obviously the cause of the nowiki. unless VE explicitly tells them where the nowiki is happening, how can we expect the newbie to figure it out.",SOLUTION DISCUSSION
244606,Tagging articles using old markup on VE,"A user at en.wp comments that if this bug remains unfixed that cleaning up the live wiki using AWB will take ""about maybe an hour of experienced editor time to manage this, every day forever, because WMF is unwilling to accept feedback on how the software is actually used.""",task_subcomment,"A user at en.wp comments that if this bug remains unfixed that cleaning up the live wiki using AWB will take ""about maybe an hour of experienced editor time to manage this, every day forever, because WMF is unwilling to accept feedback on how the software is actually used.""",FUTURE PLAN
244603,Tagging articles using old markup on VE,"**kwwilliams** wrote:

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #7)
> > > Adding a  to an article (as opposed to a template or something) is
> > > generally unnecessary and probably in need of a second look, regardless of
> > > whether VE added it or the editor added it manually.  Wikimarkup simply
> > > *doesn't look like* real punctuation, so it's uncommon to need to escape it
> > > in
> > > running text.
> > > 
> > > As such, I tentatively agree with James here: A VE-only filter would be
> > > unnecessary since the broader case is really what we need to go after anyway.
> > 
> > You miss the point: in an edit-filter, I would advocate simply blocking the
> > edit if it was VE and not allow it to be saved. If a human being consciously
> > did it, there's at least a remote chance that it was a good edit worthy of
> > examination.
> 
> I think that would be an exceptionally-bad thing to do to fellow editors and
> thus to the wiki at large

As was making VE the default editor in the first place, so it's obvious we don't agree some fundamental points.

> 
> > There *are* legitimate uses of nowiki, usually things involving bolded and
> > italicized possessives, pipe characters inside of text. It's just that none
> > of the ones created by VE have any merit.
> 
> None? None ever? Not even when a user of VisualEditor creates a bolded or
> italicised possessive? :-)

True enough. Which is why you should fix the root bug in the first place instead of pushing it downstream for everyone else to deal with: warning newbies about inserting explicit wikimarkup is obviously still inadequate, as this edit filter still fires.",task_subcomment,"**kwwilliams** wrote:

(In reply to comment #11)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

As was making VE the default editor in the first place, so it's obvious we don't agree some fundamental points.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

True enough. Which is why you should fix the root bug in the first place instead of pushing it downstream for everyone else to deal with: warning newbies about inserting explicit wikimarkup is obviously still inadequate, as this edit filter still fires.",SOLUTION DISCUSSION
244599,Tagging articles using old markup on VE,"(In reply to comment #6)
> Tell me how an abuse filter can even detect that Visual Editor was involved
> in the edit before you attempt to close this, please.

That would be bug 51421 (which is a bug against AbuseFilter); you should follow-up there.",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE

That would be bug 51421 (which is a bug against AbuseFilter); you should follow-up there.",ACTION ON ISSUE
244594,Tagging articles using old markup on VE,"(In reply to comment #10)
> (In reply to comment #7)
> > Adding a  to an article (as opposed to a template or something) is
> > generally unnecessary and probably in need of a second look, regardless of
> > whether VE added it or the editor added it manually.  Wikimarkup simply
> > *doesn't look like* real punctuation, so it's uncommon to need to escape it
> > in
> > running text.
> > 
> > As such, I tentatively agree with James here: A VE-only filter would be
> > unnecessary since the broader case is really what we need to go after anyway.
> 
> You miss the point: in an edit-filter, I would advocate simply blocking the
> edit if it was VE and not allow it to be saved. If a human being consciously
> did it, there's at least a remote chance that it was a good edit worthy of
> examination.

I think that would be an exceptionally-bad thing to do to fellow editors and thus to the wiki at large, but that's a decision for local wikis' communities to make, and not appropriate for the developers to rule on.

> There *are* legitimate uses of nowiki, usually things involving bolded and
> italicized possessives, pipe characters inside of text. It's just that none
> of the ones created by VE have any merit.

None? None ever? Not even when a user of VisualEditor creates a bolded or italicised possessive? :-)",task_subcomment,"(In reply to comment #10)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

I think that would be an exceptionally-bad thing to do to fellow editors and thus to the wiki at large, but that's a decision for local wikis' communities to make, and not appropriate for the developers to rule on.

QUOTE
QUOTE
QUOTE

None? None ever? Not even when a user of VisualEditor creates a bolded or italicised possessive? :-)",ACTION ON ISSUE
244590,Tagging articles using old markup on VE,"**kwwilliams** wrote:

(In reply to comment #7)
> Adding a  to an article (as opposed to a template or something) is
> generally unnecessary and probably in need of a second look, regardless of
> whether VE added it or the editor added it manually.  Wikimarkup simply
> *doesn't look like* real punctuation, so it's uncommon to need to escape it
> in
> running text.
> 
> As such, I tentatively agree with James here: A VE-only filter would be
> unnecessary since the broader case is really what we need to go after anyway.

You miss the point: in an edit-filter, I would advocate simply blocking the edit if it was VE and not allow it to be saved. If a human being consciously did it, there's at least a remote chance that it was a good edit worthy of examination.

There *are* legitimate uses of nowiki, usually things involving bolded and italicized possessives, pipe characters inside of text. It's just that none of the ones created by VE have any merit.",task_subcomment,"**kwwilliams** wrote:

(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

You miss the point: in an edit-filter, I would advocate simply blocking the edit if it was VE and not allow it to be saved. If a human being consciously did it, there's at least a remote chance that it was a good edit worthy of examination.

There *are* legitimate uses of nowiki, usually things involving bolded and italicized possessives, pipe characters inside of text. It's just that none of the ones created by VE have any merit.",SOLUTION DISCUSSION
244584,Tagging articles using old markup on VE,"**nykevin.norris** wrote:

But code samples and template documentation won't be in mainspace, which the current filter checks for.  Legitimate uses of  in mainspace are quite rare, so far as I know.  I suppose the articles on e.g. [[MediaWiki]] might use nowiki'd wikitext to show the readers what wikitext looks like, but other than that...",task_subcomment,"**nykevin.norris** wrote:

But code samples and template documentation won't be in mainspace, which the current filter checks for.  Legitimate uses of  in mainspace are quite rare, so far as I know.  I suppose the articles on e.g. [[MediaWiki]] might use nowiki'd wikitext to show the readers what wikitext looks like, but other than that...",SOLUTION DISCUSSION
244577,Tagging articles using old markup on VE,"Its possible the abusefilter could be made to detect veaction=edit, then the abuse filter could be made more discriminating, and probably block ve edits with nowiki's.

There are many cases where nowiki's are ment from the wikitext. In code samples documentation of templates etc. they always explicitly typed indication an intention from the user.",task_subcomment,"Its possible the abusefilter could be made to detect veaction=edit, then the abuse filter could be made more discriminating, and probably block ve edits with nowiki's.

There are many cases where nowiki's are ment from the wikitext. In code samples documentation of templates etc. they always explicitly typed indication an intention from the user.",SOLUTION DISCUSSION
244571,Tagging articles using old markup on VE,"**nykevin.norris** wrote:

Adding a  to an article (as opposed to a template or something) is generally unnecessary and probably in need of a second look, regardless of whether VE added it or the editor added it manually.  Wikimarkup simply *doesn't look like* real punctuation, so it's uncommon to need to escape it in running text.

As such, I tentatively agree with James here: A VE-only filter would be unnecessary since the broader case is really what we need to go after anyway.",task_subcomment,"**nykevin.norris** wrote:

Adding a  to an article (as opposed to a template or something) is generally unnecessary and probably in need of a second look, regardless of whether VE added it or the editor added it manually.  Wikimarkup simply *doesn't look like* real punctuation, so it's uncommon to need to escape it in running text.

As such, I tentatively agree with James here: A VE-only filter would be unnecessary since the broader case is really what we need to go after anyway.",SOLUTION DISCUSSION
244564,Tagging articles using old markup on VE,"**kwwilliams** wrote:

Tell me how an abuse filter can even detect that Visual Editor was involved in the edit before you attempt to close this, please.",task_subcomment,"**kwwilliams** wrote:

Tell me how an abuse filter can even detect that Visual Editor was involved in the edit before you attempt to close this, please.",SOLUTION DISCUSSION
244555,Tagging articles using old markup on VE,"As mentioned, there is now a local AbuseFilter running on enwiki that flags any edit that adds a  tag (whether in VisualEditor or wikitext editor; whether accidental or deliberate; whether due to using wikitext markup or because of a bug).

I think a global AbuseFilter might make sense to do this globally, but certainly this feels like something better done using AbuseFilter than heavy-handedly inserted by VisualEditor itself, if that makes sense, so I'm going to close this as a WONTFIX - but very happy to reopen if people feel it would be better in VE.",task_subcomment,"As mentioned, there is now a local AbuseFilter running on enwiki that flags any edit that adds a  tag (whether in VisualEditor or wikitext editor; whether accidental or deliberate; whether due to using wikitext markup or because of a bug).

I think a global AbuseFilter might make sense to do this globally, but certainly this feels like something better done using AbuseFilter than heavy-handedly inserted by VisualEditor itself, if that makes sense, so I'm going to close this as a WONTFIX - but very happy to reopen if people feel it would be better in VE.",ACTION ON ISSUE
244546,Tagging articles using old markup on VE,"Maybe this is something that should be tested with global filters[1] now that they are available?

[1] http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070253.html",task_subcomment,"Maybe this is something that should be tested with global filters[1] now that they are available?

[1] URL",SOLUTION DISCUSSION
244537,Tagging articles using old markup on VE,"There is now an edit filter to detect insertion of nowiki's
http://en.wikipedia.org/w/index.php?title=Special:AbuseLog&offset=&limit=500&wpSearchFilter=550",task_subcomment,"There is now an edit filter to detect insertion of nowiki's
URL",ACTION ON ISSUE
244529,Tagging articles using old markup on VE,"FYI, in the meantime, I've requested an edit filter to be added to identify nowiki tags in the main namespace on the English Wikipedia:
https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter/Requested&oldid=562811538#nowiki_in_main_namespace

There's now also one on the French Wikipedia.",task_subcomment,"FYI, in the meantime, I've requested an edit filter to be added to identify nowiki tags in the main namespace on the English Wikipedia:
URL

There's now also one on the French Wikipedia.",FUTURE PLAN
244521,Tagging articles using old markup on VE,"**nykevin.norris** wrote:

Here's an example of an edit which we'd like to be tagged in the future:

https://en.wikipedia.org/w/index.php?title=Richard_Rich,_1st_Baron_Rich&diff=562587470&oldid=562435942

In this case, the user didn't even realize they were using the VisualEditor and came to the help desk, confused:

https://en.wikipedia.org/wiki/Wikipedia:Help_desk#Problems_editing_with_beta_versions.3F",task_subcomment,"**nykevin.norris** wrote:

Here's an example of an edit which we'd like to be tagged in the future:

URL

In this case, the user didn't even realize they were using the VisualEditor and came to the help desk, confused:

URL",SOLUTION USAGE
52524,Buttons not showing up,"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",task_description,"URL

Epicgenius reports the buttons not showing up, I have his same config and was not able to reproduce the issue.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244399,Buttons not showing up,"Given that it's been 25 days without further reports or information about the original issue, I'm marking this as INVALID.",task_subcomment,"Given that it's been 25 days without further reports or information about the original issue, I'm marking this as INVALID.",ACTION ON ISSUE
244391,Buttons not showing up,Can they take a screenshot and attach to this bug? It'd be helpful to understand what it now showing up looks like.,task_subcomment,Can they take a screenshot and attach to this bug? It'd be helpful to understand what it now showing up looks like.,BUG REPRODUCTION
52521,Ghost references in VisualEditor?,"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",task_description,"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 [URL 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 URL .

It does the same for me (Vector on Chrome).

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244210,Ghost references in VisualEditor?,"Yes, same issue as bug 50380.

*** This bug has been marked as a duplicate of bug 50380 ***",task_subcomment,"Yes, same issue as bug 50380.

*** This bug has been marked as a duplicate of bug 50380 ***",BUG REPRODUCTION
244204,Ghost references in VisualEditor?,"I cant reproduce this using the example given.

It looks like this may be a dup of bug 50380.",task_subcomment,"I cant reproduce this using the example given.

It looks like this may be a dup of bug 50380.",BUG REPRODUCTION
52519,VisualEditor: Deleting all content removes input marker,"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",task_description,"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",BUG REPRODUCTION
244066,VisualEditor: Deleting all content removes input marker,"(In reply to comment #1)
> Is this the same as Bug 50947 and/or Bug 51169?

Yes; merging.

*** This bug has been marked as a duplicate of bug 50947 ***",task_subcomment,"(In reply to comment #1)
QUOTE

Yes; merging.

*** This bug has been marked as a duplicate of bug 50947 ***",ACTION ON ISSUE
244061,VisualEditor: Deleting all content removes input marker,Is this the same as Bug 50947 and/or Bug 51169?,task_subcomment,Is this the same as Bug 50947 and/or Bug 51169?,BUG REPRODUCTION
52507,Unexpected editing behavior for typing Malayalam text,"**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",task_description,"**Author:** CODE

**Description:**
I have tested VisualEditor at ml.wikipedia at the following page

URL

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**:
URL",BUG REPRODUCTION
243373,Unexpected editing behavior for typing Malayalam text,I had this problem earlier with Ubuntu/Firefox 22. Now it is found that the problem was rectified.,task_subcomment,I had this problem earlier with Ubuntu/Firefox 22. Now it is found that the problem was rectified.,BUG REPRODUCTION
52468,VisualEditor: thick line appearing,"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}",task_description,"Screenshot

See screenshot, from URL - that line near the top shouldn't be there.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11385}",BUG REPRODUCTION
240951,VisualEditor: thick line appearing,"Created attachment 13766
No thick line

**Attached**: {F11386}",task_subcomment,"Created attachment 13766
No thick line

**Attached**: {F11386}",BUG REPRODUCTION
240942,VisualEditor: thick line appearing,"The thick line is not appearing now near the top of this page.Checked in both FireFox 20 and chrome Version 26.0.1410.65 using MAC OS X 10.8.5

See the screenshots attached.

Therefore changing the status to Resolved-worksforme for now,if you get this problem again,please do reopen the bug.",task_subcomment,"The thick line is not appearing now near the top of this page.Checked in both FireFox 20 and chrome Version 26.0.1410.65 using MAC OS X 10.8.5

See the screenshots attached.

Therefore changing the status to Resolved-worksforme for now,if you get this problem again,please do reopen the bug.",ACTION ON ISSUE
52467,VisualEditor: Text wrongly being given pre-formatted format,"Screenshot

See screenshot - from https://en.wikipedia.org/wiki/Iphigenia?veaction=edit

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11382}",task_description,"Screenshot

See screenshot - from URL

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11382}",BUG REPRODUCTION
240899,VisualEditor: Text wrongly being given pre-formatted format,Fixed for some time due to changes in Parsoid. Sorry for the slowness of updating.,task_subcomment,Fixed for some time due to changes in Parsoid. Sorry for the slowness of updating.,SOLUTION USAGE
52466,VisualEditor: Links created in the userspace are treated as links to subpages,"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",task_description,"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 URL

This seems somewhat suboptimal.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
240855,VisualEditor: Links created in the userspace are treated as links to subpages,"

*** This bug has been marked as a duplicate of bug 48915 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 48915 ***",ACTION ON ISSUE
52463,VisualEditor: Error saving data to server: Failed request: error.,"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",task_description,"We have users reporting errors when trying to save on URL - 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",BUG REPRODUCTION
240730,VisualEditor: Error saving data to server: Failed request: error.,"Performance issue, fixed some time ago; sorry for slowness in replying.",task_subcomment,"Performance issue, fixed some time ago; sorry for slowness in replying.",SOLUTION USAGE
240721,VisualEditor: Error saving data to server: Failed request: error.,"It should be the same happening here http://en.wikipedia.org/w/index.php?title=U.S._Route_377_in_Texas&diff=562454441&oldid=506596182 although the user reports seeing the message _and_ still, the edit was saved.

http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Received_error_though_edit_was_saved",task_subcomment,"It should be the same happening here URL although the user reports seeing the message _and_ still, the edit was saved.

URL",BUG REPRODUCTION
52456,"VE feature request: visual ""tell"" when editing","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",task_description,"Can something - perhaps a faint background color or an outline - be added to make clear when one is in editing mode?

Copied from URL

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",SOLUTION USAGE
240291,"VE feature request: visual ""tell"" when editing","These are already covered by bug 48008 (""There is not enough UI difference between reading and editing mode"").

*** This bug has been marked as a duplicate of bug 48008 ***",task_subcomment,"These are already covered by bug 48008 (""There is not enough UI difference between reading and editing mode"").

*** This bug has been marked as a duplicate of bug 48008 ***",BUG REPRODUCTION
240287,"VE feature request: visual ""tell"" when editing","Another related request: 

It would be very nice to show changed text in a different font and/or color (or bg color), while editing. It helps seeing what you are editing. --Wickey-nl (talk) 09:34, 5 July 2013 (UTC)",task_subcomment,"Another related request: 

It would be very nice to show changed text in a different font and/or color (or bg color), while editing. It helps seeing what you are editing. --Wickey-nl (talk) 09:34, 5 July 2013 (UTC)",SOLUTION USAGE
240280,"VE feature request: visual ""tell"" when editing","Another editor suggests:

I think various editors have said this before, but I'm feeling tired right now and have found it more of a problem than usually: a page open in VE needs to look much more distinctive. Otherwise it would be too easy to forget to Save Page and then absentmindedly close the tab on a page of edits. (Especially when juggling several tabs because checking different pages - even more so because Navigation Popups don't work in VE!). Even the header bar is almost monochrome. Could we have something like a red line all the way down the left-hand margin? Perhaps it would need to be an option, as some people would hate it. But I'd certainly find it helpful and I know I'm not alone. PamD 22:00, 4 July 2013 (UTC)",task_subcomment,"Another editor suggests:

I think various editors have said this before, but I'm feeling tired right now and have found it more of a problem than usually: a page open in VE needs to look much more distinctive. Otherwise it would be too easy to forget to Save Page and then absentmindedly close the tab on a page of edits. (Especially when juggling several tabs because checking different pages - even more so because Navigation Popups don't work in VE!). Even the header bar is almost monochrome. Could we have something like a red line all the way down the left-hand margin? Perhaps it would need to be an option, as some people would hate it. But I'd certainly find it helpful and I know I'm not alone. PamD 22:00, 4 July 2013 (UTC)",SOLUTION DISCUSSION
52455,VisualEditor: Insert media dialog is borked,"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}",task_description,"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}",BUG REPRODUCTION
240255,VisualEditor: Insert media dialog is borked,"

*** This bug has been marked as a duplicate of bug 50471 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50471 ***",ACTION ON ISSUE
52437,"VisualEditor: ""Error saving data to server"" but actually successful, and spurious diff","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 (| -> |) in a section of the page I didn't edit.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"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 (URL  The second time, it did a dirty diff for a pipe character (| -> |) in a section of the page I didn't edit.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
239309,"VisualEditor: ""Error saving data to server"" but actually successful, and spurious diff",We have tweaked the time-out code so this shouldn't happen in future; sorry for the disruption. Please re-open if it recurs…,task_subcomment,We have tweaked the time-out code so this shouldn't happen in future; sorry for the disruption. Please re-open if it recurs…,ACTION ON ISSUE
52428,Preserve wiki link href with ././ prefix,"The following HTML does not seem to properly round-trip through VE:


                ./Foo
                

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",task_description,"The following HTML does not seem to properly round-trip through VE:


                ./Foo
                

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:

URL

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION DISCUSSION
238558,Preserve wiki link href with ././ prefix,"My problem is still occurring. I've now created bug 50720 for the specific issue I'm seeing. The latest occurrence was 05:07, 4 July 2013 
https://en.wikipedia.org/w/index.php?title=Austropotamobius_pallipes&curid=3945333&diff=562783871&oldid=545518009",task_subcomment,"My problem is still occurring. I've now created bug 50720 for the specific issue I'm seeing. The latest occurrence was 05:07, 4 July 2013 
URL",ACTION ON ISSUE
238555,Preserve wiki link href with ././ prefix,Note that I also deployed a fix for bug 50426 just before I closed this bug. That will avoid triggering this in VE even if there is still a bug.,task_subcomment,Note that I also deployed a fix for bug 50426 just before I closed this bug. That will avoid triggering this in VE even if there is still a bug.,SOLUTION USAGE
238552,Preserve wiki link href with ././ prefix,"WORKSFORME is not good enough for a resolution for this bug. This seems to be quite a rare bug which I've only seen in edits with the visualeditor-needcheck tag

https://en.wikipedia.org/w/index.php?title=Special:RecentChanges&tagfilter=visualeditor-needcheck 

Looking thorough that this edit
https://en.wikipedia.org/w/index.php?title=Ron_Davies_(songwriter)&curid=31118393&diff=562723238&oldid=553701771

introduced the bad markup and that was only a couple of hours ago.",task_subcomment,"WORKSFORME is not good enough for a resolution for this bug. This seems to be quite a rare bug which I've only seen in edits with the visualeditor-needcheck tag

URL 

Looking thorough that this edit
URL

introduced the bad markup and that was only a couple of hours ago.",BUG REPRODUCTION
238548,Preserve wiki link href with ././ prefix,"It worked at http://en.wikipedia.org/wiki/User:Catrope/Shrek?veaction=edit though, so closing as working.",task_subcomment,"It worked at URL though, so closing as working.",ISSUE CONTENT MANAGEMENT
238541,Preserve wiki link href with ././ prefix,"This seems to also seem to replace spaces with underscores, and mangles category links. EG changing [[Category:House (season 7) episodes]] to [[./Category:House_(season_7)_episodes]]
https://en.wikipedia.org/w/index.php?title=Out_of_the_Chute&diff=prev&oldid=562623071",task_subcomment,"This seems to also seem to replace spaces with underscores, and mangles category links. EG changing [[Category:House (season 7) episodes]] to [[./Category:House_(season_7)_episodes]]
URL",MOTIVATION
238533,Preserve wiki link href with ././ prefix,"Those prefixes actually seem to have been inserted by VE:
https://en.wikipedia.org/w/index.php?title=DreamWorks_Animation&curid=1509817&diff=562129729&oldid=562106766",task_subcomment,"Those prefixes actually seem to have been inserted by VE:
URL",BUG REPRODUCTION
52421,Feature request: permit copy-paste of templates from history,"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",task_description,"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",INVESTIGATION AND EXPLORATION
238111,Feature request: permit copy-paste of templates from history,"This will be solved by bug 41193 when that is fixed; merging to that.

*** This bug has been marked as a duplicate of bug 41193 ***",task_subcomment,"This will be solved by bug 41193 when that is fixed; merging to that.

*** This bug has been marked as a duplicate of bug 41193 ***",ACTION ON ISSUE
238106,Feature request: permit copy-paste of templates from history,"I believe Maggie means copying the VisualEditor representation of a template, not copying wikitext.",task_subcomment,"I believe Maggie means copying the VisualEditor representation of a template, not copying wikitext.",SOLUTION DISCUSSION
238102,Feature request: permit copy-paste of templates from history,"Even if you could paste it in, that wouldn't do any good as the VE would surround the template with  tags. Entering any form of wikisyntax in the VE currently results in the editor thinking that you want the literal text to be displayed. This bug therefore (partly) depends on that bug being fixed too.",task_subcomment,"Even if you could paste it in, that wouldn't do any good as the VE would surround the template with  tags. Entering any form of wikisyntax in the VE currently results in the editor thinking that you want the literal text to be displayed. This bug therefore (partly) depends on that bug being fixed too.",BUG REPRODUCTION
52418,VisualEditor: Backspace from header line into empty paragraph changes header format into paragraph,"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",task_description,"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**:
URL",BUG REPRODUCTION
237967,VisualEditor: Backspace from header line into empty paragraph changes header format into paragraph,"The initial behaviour was, I believe, fixed some time ago; the rest of the bug (as now stated in the title) is intentional behaviour. Marking as FIXED.",task_subcomment,"The initial behaviour was, I believe, fixed some time ago; the rest of the bug (as now stated in the title) is intentional behaviour. Marking as FIXED.",ACTION ON ISSUE
237959,VisualEditor: Backspace from header line into empty paragraph changes header format into paragraph,"Sorry: I should have said ""Backspace"", not ""Delete"".",task_subcomment,"Sorry: I should have said ""Backspace"", not ""Delete"".",BUG REPRODUCTION
52417,VisualEditor does not load on Opera when debugging with Dragonfly,"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 (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 (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 () 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 (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 (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 [, ] on Firefox. Since `index` is not undefined, this would indicate some sort of an internal inconsistency.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"Would you believe that.

[6/29/2013 1:44:17 PM] JavaScript - URL
Event thread: readystatechange
Uncaught exception: Error: WRONG_ARGUMENTS_ERRError thrown at line 39, column 4 in (domElement) in URL
    return doc ? doc.importNode(domElement, true) : domElement.cloneNode(true);
called from line 38, column 3 in (domElements, doc) in URL
    return domElements.map(function(domElement) {
called from line 9721, column 3 in () in URL
    this.$.empty().append(ve.copyDomElements(store.value(index), doc));
called from line 9711, column 2 in VeCeGeneratedContentNode() in URL
    this.onUpdate();
called via Function.prototype.call() from line 10325, column 2 in VeCeMWTransclusionNode(model, config) in URL
    ve.ce.GeneratedContentNode.call(this);
called via Function.prototype.call() from line 10366, column 2 in VeCeMWTransclusionBlockNode(model) in URL
    ve.ce.MWTransclusionNode.call(this, model);
called via Function.prototype.apply() from line 50, column 2 in (name) in URL
    constructor.apply(obj, args);
called from line 8132, column 4 in (index) in URL
    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 URL
    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 URL
    ve.ce.BranchNode.call(this, model, config);

At this point CODE is [undefined, undefined] on Opera, but [, ] on Firefox. Since CODE is not undefined, this would indicate some sort of an internal inconsistency.

--------------------------
**Version**: unspecified
**Severity**: normal",INVESTIGATION AND EXPLORATION
237907,VisualEditor does not load on Opera when debugging with Dragonfly,"Change 71174 merged by jenkins-bot:
Make loading VE work on Opera again, attempt two

https://gerrit.wikimedia.org/r/71174",task_subcomment,"Change 71174 merged by jenkins-bot:
Make loading VE work on Opera again, attempt two

GERRIT_URL",SOLUTION USAGE
237902,VisualEditor does not load on Opera when debugging with Dragonfly,"Change 71174 had a related patch set uploaded by Matmarex:
Make loading VE work on Opera again, attempt two

https://gerrit.wikimedia.org/r/71174",task_subcomment,"Change 71174 had a related patch set uploaded by Matmarex:
Make loading VE work on Opera again, attempt two

GERRIT_URL",SOLUTION USAGE
237896,VisualEditor does not load on Opera when debugging with Dragonfly,I know why it only fails when debugging: because the fix in https://gerrit.wikimedia.org/r/#/c/61560/ is only applied when not debugging. Apparently the document there is *still* not a document evenif it appears to be one.,task_subcomment,I know why it only fails when debugging: because the fix in URL is only applied when not debugging. Apparently the document there is *still* not a document evenif it appears to be one.,BUG REPRODUCTION
237889,VisualEditor does not load on Opera when debugging with Dragonfly,"And that is because #cloneNode is returning `undefined` for those elements (probably because they come from some weird dynamically-generated document). Which is clearly an Opera bug, but it'd be nice to work around it somehow.",task_subcomment,"And that is because #cloneNode is returning CODE for those elements (probably because they come from some weird dynamically-generated document). Which is clearly an Opera bug, but it'd be nice to work around it somehow.",BUG REPRODUCTION
237882,VisualEditor does not load on Opera when debugging with Dragonfly,"And this is because ve.copyArray() is losing data, always returning an array of undefineds there.",task_subcomment,"And this is because ve.copyArray() is losing data, always returning an array of undefineds there.",BUG REPRODUCTION
237874,VisualEditor does not load on Opera when debugging with Dragonfly,"Hey, it's even better – all of the arrays in store.valueStore apparently consist only of varying number of undefineds.",task_subcomment,"Hey, it's even better – all of the arrays in store.valueStore apparently consist only of varying number of undefineds.",BUG REPRODUCTION
52416,"Text covered up by infobox when editing, if image in infobox is large","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",task_description,"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 URL 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",BUG REPRODUCTION
237836,"Text covered up by infobox when editing, if image in infobox is large","Congrats on your first bug report; sadly it is a dupe. Took me a while to find  bug 49925 though, so you are forgiven :)

*** This bug has been marked as a duplicate of bug 49925 ***",task_subcomment,"Congrats on your first bug report; sadly it is a dupe. Took me a while to find  bug 49925 though, so you are forgiven :)

*** This bug has been marked as a duplicate of bug 49925 ***",ACTION ON ISSUE
52380,VisualEditor: massively duplicating references on render,"https://en.wikipedia.org/wiki/Birbal has 3 references; https://en.wikipedia.org/wiki/Birbal?veaction=edit has 24.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"URL has 3 references; URL has 24.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
235754,VisualEditor: massively duplicating references on render,*** Bug 50521 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50521 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
235749,VisualEditor: massively duplicating references on render,Fixed a few months ago; sorry for late reply.,task_subcomment,Fixed a few months ago; sorry for late reply.,SOLUTION USAGE
235743,VisualEditor: massively duplicating references on render,"They both have 21 references now. :P

I see there were three references around the time of the bug entry
https://en.wikipedia.org/w/index.php?title=Birbal&oldid=561978332

We need to figure out how to make this problem reproducible.

(bug 50521 looks similar, and might provide some clues on how to cause the renderer to get into this odd state)",task_subcomment,"They both have 21 references now. :P

I see there were three references around the time of the bug entry
URL

We need to figure out how to make this problem reproducible.

(bug 50521 looks similar, and might provide some clues on how to cause the renderer to get into this odd state)",BUG REPRODUCTION
52364,"VisualEditor: Toolbar shows on top of Save dialog, prevents saving","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}",task_description,"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}",BUG REPRODUCTION
234639,"VisualEditor: Toolbar shows on top of Save dialog, prevents saving","I think this is 50324 instead.

*** This bug has been marked as a duplicate of bug 50324 ***",task_subcomment,"I think this is 50324 instead.

*** This bug has been marked as a duplicate of bug 50324 ***",ACTION ON ISSUE
52361,VisualEditor: modifying some templates causes them to collapse in on themselves in edit mode,"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}",task_description,"Screenshot

Try modifying the infobox in URL for example - see the screenshot.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11137}",BUG REPRODUCTION
234513,VisualEditor: modifying some templates causes them to collapse in on themselves in edit mode,"

*** This bug has been marked as a duplicate of bug 49854 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 49854 ***",ACTION ON ISSUE
52359,"VisualEditor: Can't drag and drop transclusions, text, references","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",task_description,"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",EXPECTED BEHAVIOR
234439,"VisualEditor: Can't drag and drop transclusions, text, references","Actually, bug 49981 is meant to cover everything; merging.

*** This bug has been marked as a duplicate of bug 49981 ***",task_subcomment,"Actually, bug 49981 is meant to cover everything; merging.

*** This bug has been marked as a duplicate of bug 49981 ***",ACTION ON ISSUE
234431,"VisualEditor: Can't drag and drop transclusions, text, references","While for text there's 49981 open, itwp users also request this for templates.",task_subcomment,"While for text there's 49981 open, itwp users also request this for templates.",POTENTIAL NEW ISSUES AND REQUESTS
52331,VisualEditor throws  next to any square bracket [,"It is usual to use [square brackets], [...] inside quotes to cut or complete sentences in quotes. As for today, VisualEditor will add  tags like this:

[Square brackets]

[...]

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  tags.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T54268}",task_description,"It is usual to use [square brackets], [...] inside quotes to cut or complete sentences in quotes. As for today, VisualEditor will add  tags like this:

[Square brackets]

[...]

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  tags.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
{T54268}",BUG REPRODUCTION
232663,VisualEditor throws  next to any square bracket [,"This bug was about single square brackets ([ ... ]), not wikitext links. 

Entering [[Foo]] as text will practically always need to be escaped as the rules for valid page titles are less restrictive than those for absolute URLs. Same is true for linking parts of a word where the remainder of the word would become part of the link via the link trail mechanism (aka- less precisely- 'piped links'). Or entering any other random wikitext in the VE. Not escaping such wikitext would break the WYSIWYG promise.",task_subcomment,"This bug was about single square brackets ([ ... ]), not wikitext links. 

Entering [[Foo]] as text will practically always need to be escaped as the rules for valid page titles are less restrictive than those for absolute URLs. Same is true for linking parts of a word where the remainder of the word would become part of the link via the link trail mechanism (aka- less precisely- 'piped links'). Or entering any other random wikitext in the VE. Not escaping such wikitext would break the WYSIWYG promise.",SOLUTION DISCUSSION
232654,VisualEditor throws  next to any square bracket [,"Not really sure if this applies as well, but will leave it here: http://en.wikipedia.org/w/index.php?title=Ingress_(game)&diff=prev&oldid=562432188 

from
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Strange_result_with_a_.3C.2Fnowiki.3E_tag_inserted .
Thanks.",task_subcomment,"Not really sure if this applies as well, but will leave it here: URL 

from
URL .
Thanks.",SOLUTION USAGE
232646,VisualEditor throws  next to any square bracket [,"Looks like we are either still have a problem or it may have resurfaced; last section of:

http://en.wikipedia.org/w/index.php?title=Raphael_Sch%C3%A4fer&diff=prev&oldid=562506378

and follow up edits.",task_subcomment,"Looks like we are either still have a problem or it may have resurfaced; last section of:

URL

and follow up edits.",BUG REPRODUCTION
232640,VisualEditor throws  next to any square bracket [,We have refined the nowiki escaping in Parsoid so that external link like syntax that does not have a valid target is no longer escaped.,task_subcomment,We have refined the nowiki escaping in Parsoid so that external link like syntax that does not have a valid target is no longer escaped.,SOLUTION DISCUSSION
52313,VisualEditor: Cutting the text of a header leaves a blank header line behind,"Fairly self-explanatory.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"Fairly self-explanatory.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION DISCUSSION
231451,VisualEditor: Cutting the text of a header leaves a blank header line behind,"This is bug 50100.

*** This bug has been marked as a duplicate of bug 50100 ***",task_subcomment,"This is bug 50100.

*** This bug has been marked as a duplicate of bug 50100 ***",ACTION ON ISSUE
231443,VisualEditor: Cutting the text of a header leaves a blank header line behind,"Removing a paragraph and header does the same - https://en.wikipedia.org/w/index.php?title=Idlib_Governorate_clashes_%28June_2012%E2%80%93present%29&curid=39240723&diff=562677456&oldid=562663343

Can this please be prioritised and assigned?",task_subcomment,"Removing a paragraph and header does the same - URL

Can this please be prioritised and assigned?",ACTION ON ISSUE
52312,VisualEditor: edit link on the history page needs updating,"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",task_description,"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",EXPECTED BEHAVIOR
231398,VisualEditor: edit link on the history page needs updating,"How very strange. Slightly slower loading time giving a false impression, probably; thanks :).",task_subcomment,"How very strange. Slightly slower loading time giving a false impression, probably; thanks :).",SOLUTION DISCUSSION
231391,VisualEditor: edit link on the history page needs updating,"Do you mean the diff page - e.g. https://en.wikipedia.org/w/index.php?title=Barack_Obama&diff=561813443&oldid=561813311 - the history page e.g. https://en.wikipedia.org/wiki/Barack_Obama?action=history - or the oldid page - e.g. https://en.wikipedia.org/w/index.php?title=Barack_Obama&oldid=561813443 ?

'Cos the second two work for me; the first one isn't a history page, though. :-)",task_subcomment,"Do you mean the diff page - e.g. URL - the history page e.g. URL - or the oldid page - e.g. URL ?

'Cos the second two work for me; the first one isn't a history page, though. :-)",TASK PROGRESS
52295,Carriage return shows up among text,"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}",task_description,"This is what Alberobello looks like under VE

When trying to edit URL (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 URL : the line which says ""Test split on multiple lines""? It isn't.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11918}",MOTIVATION
255695,Carriage return shows up among text,"(In reply to comment #0)
> Created attachment 12662 [details]
> 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.

This is because the blank line is a 'slug' - see bug 47790 for further discussion.

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

It's a test of whether you can edit the caption with multiple lines for it to display correctly; it's not meant to actually end up on multiple lines, which is why it shows up with '↵'s instead.

*** This bug has been marked as a duplicate of bug 47790 ***

**Attached**: {F11918}",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This is because the blank line is a 'slug' - see bug 47790 for further discussion.

QUOTE
QUOTE
QUOTE
QUOTE

It's a test of whether you can edit the caption with multiple lines for it to display correctly; it's not meant to actually end up on multiple lines, which is why it shows up with '↵'s instead.

*** This bug has been marked as a duplicate of bug 47790 ***

**Attached**: {F11918}",ACTION ON ISSUE
52293,ULS doesn't work while using VisualEditor,"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}",task_description,"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: URL on Mac OS X 10.7.5 using browser Firefox 21.0.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11913}",BUG REPRODUCTION
255613,ULS doesn't work while using VisualEditor,"

*** This bug has been marked as a duplicate of bug 49569 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 49569 ***",ACTION ON ISSUE
52290,VisualEditor: not permitting interaction with some media files (and formatting them weirdly),"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",task_description,"See URL - 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",BUG REPRODUCTION
255457,VisualEditor: not permitting interaction with some media files (and formatting them weirdly),"This would have been bug 48900 in Parsoid.

*** This bug has been marked as a duplicate of bug 48900 ***",task_subcomment,"This would have been bug 48900 in Parsoid.

*** This bug has been marked as a duplicate of bug 48900 ***",ACTION ON ISSUE
52283,VisualEditor: references cannot be copied and pasted without losing formatting,"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 Jones (2003) p.23 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",task_description,"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 Jones (2003) p.23 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",SOLUTION DISCUSSION
254975,VisualEditor: references cannot be copied and pasted without losing formatting,"This should be addressed when bug 33105 is fixed.

*** This bug has been marked as a duplicate of bug 33105 ***",task_subcomment,"This should be addressed when bug 33105 is fixed.

*** This bug has been marked as a duplicate of bug 33105 ***",ACTION ON ISSUE
52278,VisualEditor: Page settings dialog adds categories with [[:Category:xyz]] syntax,"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",task_description,"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",BUG REPRODUCTION
254768,VisualEditor: Page settings dialog adds categories with [[:Category:xyz]] syntax,"This was a Parsoid bug, since fixed.",task_subcomment,"This was a Parsoid bug, since fixed.",SOLUTION DISCUSSION
52276,VisualEditor: Toolbar obscures save dialog when scrolled down the page,"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}",task_description,"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}",BUG REPRODUCTION
254685,VisualEditor: Toolbar obscures save dialog when scrolled down the page,"

*** This bug has been marked as a duplicate of bug 50324 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50324 ***",ACTION ON ISSUE
52267,VisualEditor: not adhering to column numbers when rendering,"See https://en.wikipedia.org/wiki/Microorganism?veaction=edit#See_also for example; that should be divided into 3 columns.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See URL for example; that should be divided into 3 columns.

--------------------------
**Version**: unspecified
**Severity**: normal",TASK PROGRESS
254255,VisualEditor: not adhering to column numbers when rendering,"This is almost certainly the same as bug 50036.

*** This bug has been marked as a duplicate of bug 50036 ***",task_subcomment,"This is almost certainly the same as bug 50036.

*** This bug has been marked as a duplicate of bug 50036 ***",ACTION ON ISSUE
52258,Unwanted Removal of text formatting,"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",task_description,"In this edit:URL

Bold/italic formatting was removed by an unrelated action (addition of text).  See editor's description here:URL

--------------------------
**Version**: unspecified
**Severity**: major",SOLUTION USAGE
253767,Unwanted Removal of text formatting,"Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!

*** This bug has been marked as a duplicate of bug 50068 ***",task_subcomment,"Hey, yeah, this is a really irritating bug in Parsoid - bug 50068 - so marking this as a duplicate of that bug. Thanks for highlighting it, though - really important we try to fix this ASAP, and being reminded helps focus us!

*** This bug has been marked as a duplicate of bug 50068 ***",ACTION ON ISSUE
253759,Unwanted Removal of text formatting,Duplicated here: http://test.wikipedia.org/w/index.php?title=VisualEditor%3ATestingGrounds&diff=174932&oldid=174931,task_subcomment,Duplicated here: URL,ACTION ON ISSUE
52249,'become' doesn't load ~/.bashrc,"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",task_description,"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",SOLUTION USAGE
253307,'become' doesn't load ~/.bashrc,"Works as designed.

become, through sudo, creates an interactive login shell.  To quote from the bash info page:

"" When Bash is invoked as an interactive login shell, or as a
  non-interactive shell with the `--login' option, it first reads and
  executes commands from the file `/etc/profile', if that file exists.
  After reading that file, it looks for `~/.bash_profile',
  `~/.bash_login', and `~/.profile', in that order, and reads and
  executes commands from the first one that exists and is readable.""

A thing many users may want to do to simplify things is to have a ~/.profile that sources ~/.bashrc (in addition or instead of login-specific behaviour) so that the latter gets sourced regardless of how the shell was invoked.",task_subcomment,"Works as designed.

become, through sudo, creates an interactive login shell.  To quote from the bash info page:

"" When Bash is invoked as an interactive login shell, or as a
  non-interactive shell with the CODE/etc/profile', if that file exists.
  After reading that file, it looks for CODE~/.bash_login', and `~/.profile', in that order, and reads and
  executes commands from the first one that exists and is readable.""

A thing many users may want to do to simplify things is to have a ~/.profile that sources ~/.bashrc (in addition or instead of login-specific behaviour) so that the latter gets sourced regardless of how the shell was invoked.",SOLUTION DISCUSSION
52248,screen doesn't work from within 'become',"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",task_description,"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",BUG REPRODUCTION
253280,screen doesn't work from within 'become',"valhallasw@tools-login:~$ chown valhallasw:tools.tsreports /dev/pts/164
valhallasw@tools-login:~$ chmod g+r /dev/pts/164
valhallasw@tools-login:~$ become tsreports
tools.tsreports@tools-login:~$ screen

This works for me. I suppose there still is some security impact with this (I guess all tsreports users can now read my TTY? but that might already be possible when I 'become tsreports'?) but it's somewhat less extreme. 


Alternatively, could log_input be used to redirect to /dev/null, thus mitigating the risk of log files?",task_subcomment,"valhallasw@tools-login:~$ chown valhallasw:tools.tsreports /dev/pts/164
valhallasw@tools-login:~$ chmod g+r /dev/pts/164
valhallasw@tools-login:~$ become tsreports
tools.tsreports@tools-login:~$ screen

This works for me. I suppose there still is some security impact with this (I guess all tsreports users can now read my TTY? but that might already be possible when I 'become tsreports'?) but it's somewhat less extreme. 


Alternatively, could log_input be used to redirect to /dev/null, thus mitigating the risk of log files?",SOLUTION DISCUSSION
253273,screen doesn't work from within 'become',"That will not be changed from the current method; automatically logging I/O is an unacceptable security risk, especially if it happens unconditionally and without the user's knowledge/consent.

Run screen from your own user, or use screen to created a tty for the task.",task_subcomment,"That will not be changed from the current method; automatically logging I/O is an unacceptable security risk, especially if it happens unconditionally and without the user's knowledge/consent.

Run screen from your own user, or use screen to created a tty for the task.",SOLUTION DISCUSSION
253268,screen doesn't work from within 'become',".bash_history records the commands you typed at the shell prompt that were actually submitted; recording the stream would include everything sent and/or received, including keystrokes to applications, typed passwords, etc.  For instance, if you mistakenly start to type a password in your ssh session because your focus was on the wrong window then backspace over it, .bash_history would not record it, log_input and log_output would.

Another difference is that you can manage (delete, edit, verify) your .bash_history, whereas logged I/O is neither visible nor under your control.

The logged I/O would only be available to roots; but much of that is stuff that I wouldn't want to exist on disk even granted perfect trust in everyone involved.  An accident that leaves /var/log/sudo-io/ accessible or a security flaw that allows escalation would expose that data -- on the instance or even the host.

Key recording is just too much of an exposure, especially since the only putative benefit is the very marginal convenience of being able to start a screen session after sudo rather than just before it.",task_subcomment,".bash_history records the commands you typed at the shell prompt that were actually submitted; recording the stream would include everything sent and/or received, including keystrokes to applications, typed passwords, etc.  For instance, if you mistakenly start to type a password in your ssh session because your focus was on the wrong window then backspace over it, .bash_history would not record it, log_input and log_output would.

Another difference is that you can manage (delete, edit, verify) your .bash_history, whereas logged I/O is neither visible nor under your control.

The logged I/O would only be available to roots; but much of that is stuff that I wouldn't want to exist on disk even granted perfect trust in everyone involved.  An accident that leaves /var/log/sudo-io/ accessible or a security flaw that allows escalation would expose that data -- on the instance or even the host.

Key recording is just too much of an exposure, especially since the only putative benefit is the very marginal convenience of being able to start a screen session after sudo rather than just before it.",SOLUTION DISCUSSION
253264,screen doesn't work from within 'become',"(In reply to comment #6)
> ... at the cost of, you know, logging all the input and output of your
> session.
> 
> Needless to say, that will not happen in Tool Labs -- even having the
> capability to replay users' sessions (including passwords typed and all!)
> would be a *massive* violation of privacy.

Would it? What's the difference between this and .bash_history?

Is the logged input/output available to all users or only to roots (and the session owner)?",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Would it? What's the difference between this and .bash_history?

Is the logged input/output available to all users or only to roots (and the session owner)?",MOTIVATION
253260,screen doesn't work from within 'become',"Oh!  I figured out how they do it:  they have turned on log_input, log_output or both in their sudo configuration -- this causes the creation of a pty (like script does), and thus neatly circumvents the problem; the tty of the sudo-ed user is brand new and owned by the user.

... at the cost of, you know, logging all the input and output of your session.

Needless to say, that will not happen in Tool Labs -- even having the capability to replay users' sessions (including passwords typed and all!) would be a *massive* violation of privacy.

I'm forced to wonder whether users of toolserver are aware that their sessions are logged in this way.",task_subcomment,"Oh!  I figured out how they do it:  they have turned on log_input, log_output or both in their sudo configuration -- this causes the creation of a pty (like script does), and thus neatly circumvents the problem; the tty of the sudo-ed user is brand new and owned by the user.

... at the cost of, you know, logging all the input and output of your session.

Needless to say, that will not happen in Tool Labs -- even having the capability to replay users' sessions (including passwords typed and all!) would be a *massive* violation of privacy.

I'm forced to wonder whether users of toolserver are aware that their sessions are logged in this way.",INVESTIGATION AND EXPLORATION
253257,screen doesn't work from within 'become',"I can't tell; I don't have a MMP on the toolserver, and a cursory inspection of nightshade shows that screen isn't suid to root, which means that it should not be possible for it to open the tty when invoked from a sudo-ed user:

crw--w---- 1 marc tty 136, 31 Sep  5 04:39 /dev/pts/31

Whereas:

-rwxr-sr-x 1 root utmp 364088 Jul 29  2009 /usr/bin/screen

meaning that screen runs with the privileges of the invoking user, who would not have permission to open the terminal.  Can you switch to an MMP account and do a ""ls -l `tty`"" to see if something funky is going on with the terminal's permissions?  That might give me a hint.

The hack with script is exactly that -- a hack: it creates a new shell, a new terminal pair, and has a process running busy shuffling the data between both sides of the pipe, with a copy to /dev/null.  At best, it is horribly wasteful and doubles context switches.",task_subcomment,"I can't tell; I don't have a MMP on the toolserver, and a cursory inspection of nightshade shows that screen isn't suid to root, which means that it should not be possible for it to open the tty when invoked from a sudo-ed user:

crw--w---- 1 marc tty 136, 31 Sep  5 04:39 /dev/pts/31

Whereas:

-rwxr-sr-x 1 root utmp 364088 Jul 29  2009 /usr/bin/screen

meaning that screen runs with the privileges of the invoking user, who would not have permission to open the terminal.  Can you switch to an MMP account and do a ""ls -l CODE"" to see if something funky is going on with the terminal's permissions?  That might give me a hint.

The hack with script is exactly that -- a hack: it creates a new shell, a new terminal pair, and has a process running busy shuffling the data between both sides of the pipe, with a copy to /dev/null.  At best, it is horribly wasteful and doubles context switches.",INVESTIGATION AND EXPLORATION
253253,screen doesn't work from within 'become',"According to , it is possible on the Linux hosts, but not on the Solaris hosts. I just confirmed: dbreps@willow.toolserver.org (Solaris) gets the same error as above while dbreps@nightshade.toolserver.org (Linux) has no issue starting screen.

The Toolserver folks had a workaround for Solaris hosts (using `ttyallow`), but now we've reached a new question: what did the Toolserver do on its Linux hosts to resolve this issue that Labs hasn't done?",task_subcomment,"According to  to no avail. On IRC, I was told (by a bot, no less) that running ""script /dev/null"" is a workaround. It seems Roan found another workaround.

At a minimum, this needs to be documented (which I'll do momentarily) and the error message could be hacked to be clearer what the hell is happening (""check /dev/pts/50"" is pretty much an online equivalent of ""go fuck yourself""). Re-opening this for further thought and consideration.",task_subcomment,"I don't remember the Toolserver having this issue. This doesn't seem like a wontfix to me. This is pretty awful behavior currently. Surely we can do better.

local-dbreps@tools-login:~$ screen
Cannot open your terminal '/dev/pts/50' - please check.

I kept getting this. I checked  (In reply to comment #0)
> > 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.
> 
> Is this in Monobook or in Vector? AFAICS this works for me in Vector fine; in
> Monobook, there's the bug 50241 issue but that's it.

Aha, tracked it down:

Uncaught Error: Offset could not be translated to a DOM element and offset: 136 ve.ce.Document.js:187
ve.ce.Document.getNodeAndOffset ve.ce.Document.js:187
ve.ce.Surface.showSelection ve.ce.Surface.js:1296
ve.ce.Surface.onChange ve.ce.Surface.js:745
oo.EventEmitter.emit oo.js:421
ve.dm.Surface.change ve.dm.Surface.js:402
ve.dm.SurfaceFragment.insertContent ve.dm.SurfaceFragment.js:581
ve.ui.MWTransclusionDialog.onClose ve.ui.MWTransclusionDialog.js:110
ve.ui.Window.close ve.ui.Window.js:328
(anonymous function) ve.ui.Dialog.js:118
proxy load.php:775


This is bug 47947 - which we really need to fix now. :-(

*** This bug has been marked as a duplicate of bug 47947 ***",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Aha, tracked it down:

Uncaught Error: Offset could not be translated to a DOM element and offset: 136 ve.ce.Document.js:187
ve.ce.Document.getNodeAndOffset ve.ce.Document.js:187
ve.ce.Surface.showSelection ve.ce.Surface.js:1296
ve.ce.Surface.onChange ve.ce.Surface.js:745
oo.EventEmitter.emit oo.js:421
ve.dm.Surface.change ve.dm.Surface.js:402
ve.dm.SurfaceFragment.insertContent ve.dm.SurfaceFragment.js:581
ve.ui.MWTransclusionDialog.onClose ve.ui.MWTransclusionDialog.js:110
ve.ui.Window.close ve.ui.Window.js:328
(anonymous function) ve.ui.Dialog.js:118
proxy load.php:775


This is bug 47947 - which we really need to fix now. :-(

*** This bug has been marked as a duplicate of bug 47947 ***",BUG REPRODUCTION
252966,VisualEditor: Dialogs won't open after adding a template at the end of the page,"(In reply to comment #0)
> 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.

Is this in Monobook or in Vector? AFAICS this works for me in Vector fine; in Monobook, there's the bug 50241 issue but that's it.",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE

Is this in Monobook or in Vector? AFAICS this works for me in Vector fine; in Monobook, there's the bug 50241 issue but that's it.",MOTIVATION
52226,VisualEditor not working due to unflushed ResourceLoader cache?,"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",task_description,"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",BUG REPRODUCTION
251967,VisualEditor not working due to unflushed ResourceLoader cache?,"(In reply to comment #2)
> I assume this is obsolete now?

Sorry, yes, we got this fixed; thanks Sam, and thanks for the follow-up, Andre.",task_subcomment,"(In reply to comment #2)
QUOTE

Sorry, yes, we got this fixed; thanks Sam, and thanks for the follow-up, Andre.",SOLUTION USAGE
251961,VisualEditor not working due to unflushed ResourceLoader cache?,I assume this is obsolete now?,task_subcomment,I assume this is obsolete now?,SOLUTION USAGE
251955,VisualEditor not working due to unflushed ResourceLoader cache?,"I think we fixed this with a touch on ve.js by Reedy - please confirm? (Gah, forgot to say this 3 hours ago.)",task_subcomment,"I think we fixed this with a touch on ve.js by Reedy - please confirm? (Gah, forgot to say this 3 hours ago.)",SOLUTION USAGE
52213,VisualEditor: Extra bullet point before template containing bulleted list,"VE rendering of [[WUEC#External_links]] does not match MW rendering.

--------------------------
**Version**: unspecified
**Severity**: minor",task_description,"VE rendering of [[WUEC#External_links]] does not match MW rendering.

--------------------------
**Version**: unspecified
**Severity**: minor",BUG REPRODUCTION
251257,VisualEditor: Extra bullet point before template containing bulleted list,"This is a slightly-faulty use of wikitext on the page - it dereferences to

*[http://www.wpr.org/ Wisconsin Public Radio]
*{{FM station data|WUEC}}

->

*[http://www.wpr.org/ Wisconsin Public Radio]
*
*{{FMQ|WUEC}}
*{{FML|WUEC}}
*{{FMARB|WUEC}}

… and gets displayed as such, in case you want to edit that otherwise-inexpliably-hidden bullet. Marking as INVALID (but yeah, eww at that wikitext).",task_subcomment,"This is a slightly-faulty use of wikitext on the page - it dereferences to

*[URL Wisconsin Public Radio]
*{{FM station data|WUEC}}

->

*[URL Wisconsin Public Radio]
*
*{{FMQ|WUEC}}
*{{FML|WUEC}}
*{{FMARB|WUEC}}

… and gets displayed as such, in case you want to edit that otherwise-inexpliably-hidden bullet. Marking as INVALID (but yeah, eww at that wikitext).",ACTION ON ISSUE
52211,VisualEditor: References prevent floats from being selected and edited,"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}",task_description,"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}",BUG REPRODUCTION
251151,VisualEditor: References prevent floats from being selected and edited,"Entirely-confusingly, this is the same as bug 50395 (which is more detailed, so I'll up-merge this into that one). Sorry for the slow update.

*** This bug has been marked as a duplicate of bug 50395 ***",task_subcomment,"Entirely-confusingly, this is the same as bug 50395 (which is more detailed, so I'll up-merge this into that one). Sorry for the slow update.

*** This bug has been marked as a duplicate of bug 50395 ***",ACTION ON ISSUE
52210,VisualEditor: Opening Page settings dialog doesn't close heading format drop-down,"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}",task_description,"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}",BUG REPRODUCTION
251095,VisualEditor: Opening Page settings dialog doesn't close heading format drop-down,"This is still true (and deliberate), but since our major re-vamp of how windows stack on top of one another, no longer an issue; closing as FIXED.",task_subcomment,"This is still true (and deliberate), but since our major re-vamp of how windows stack on top of one another, no longer an issue; closing as FIXED.",ACTION ON ISSUE
52207,VisualEditor: Image size parameter with spaces is ignored,"See [[testwiki:VisualEditor:Little or big]].

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See [[testwiki:VisualEditor:Little or big]].

--------------------------
**Version**: unspecified
**Severity**: normal",TESTING
250900,VisualEditor: Image size parameter with spaces is ignored,"

*** This bug has been marked as a duplicate of bug 49696 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 49696 ***",ACTION ON ISSUE
52204,Logging broken for GettingStarted (page-save-success logged as page-impression),"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
250671,Logging broken for GettingStarted (page-save-success logged as page-impression),"Looks properly fixed with the 2013-07-18 rollout of wmf10 to enwiki that included this fix, plus and later that day the changes to restore GettingStarted after CentralAuth/SUL2 changed.

SELECT LEFT( timestamp, 8), COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = ""enwiki"" AND event_action = ""page-save-success"" AND event_funnel = ""returnto"" GROUP BY 1;

+---------------------+----------+
| LEFT( timestamp, 8) | COUNT(*) |
+---------------------+----------+
| 20130702            |        1 |
| 20130718            |       17 |
| 20130719            |      235 |
+---------------------+----------+",task_subcomment,"Looks properly fixed with the 2013-07-18 rollout of wmf10 to enwiki that included this fix, plus and later that day the changes to restore GettingStarted after CentralAuth/SUL2 changed.

SELECT LEFT( timestamp, 8), COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = ""enwiki"" AND event_action = ""page-save-success"" AND event_funnel = ""returnto"" GROUP BY 1;

+---------------------+----------+
| LEFT( timestamp, 8) | COUNT(*) |
+---------------------+----------+
| 20130702            |        1 |
| 20130718            |       17 |
| 20130719            |      235 |
+---------------------+----------+",SOLUTION USAGE
250664,Logging broken for GettingStarted (page-save-success logged as page-impression),"**swalling** wrote:

https://gerrit.wikimedia.org/r/#/c/71575/ was scheduled to be deployed last week, but we flubbed a bit and it did not go out to 1.22wmf9 until today. 

I am still seeing only one page-save-success in the returnto funnel as of today, so the patch not getting deployed may be the likely culprit.",task_subcomment,"**swalling** wrote:

URL was scheduled to be deployed last week, but we flubbed a bit and it did not go out to 1.22wmf9 until today. 

I am still seeing only one page-save-success in the returnto funnel as of today, so the patch not getting deployed may be the likely culprit.",TASK PROGRESS
250657,Logging broken for GettingStarted (page-save-success logged as page-impression),"There are still no page-save-success + returnto events in prod, so there may be an RL issue.

Re-opening until we're sure it's fixed.

A relevant query is:

SELECT COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = ""enwiki""
AND event_action = ""page-save-success"" AND event_funnel = ""returnto"";",task_subcomment,"There are still no page-save-success + returnto events in prod, so there may be an RL issue.

Re-opening until we're sure it's fixed.

A relevant query is:

SELECT COUNT(*) FROM GettingStartedNavbar_5588671 WHERE wiki = ""enwiki""
AND event_action = ""page-save-success"" AND event_funnel = ""returnto"";",SOLUTION DISCUSSION
250652,Logging broken for GettingStarted (page-save-success logged as page-impression),*** Bug 51208 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51208 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
250648,Logging broken for GettingStarted (page-save-success logged as page-impression),"S's patch fixes the post-edit issue locally, which I believe is the same one I mentioned in comment 1.",task_subcomment,"S's patch fixes the post-edit issue locally, which I believe is the same one I mentioned in comment 1.",SOLUTION DISCUSSION
250644,Logging broken for GettingStarted (page-save-success logged as page-impression),"Change 71575 merged by jenkins-bot:
postEdit needs to run before GS logging

https://gerrit.wikimedia.org/r/71575",task_subcomment,"Change 71575 merged by jenkins-bot:
postEdit needs to run before GS logging

GERRIT_URL",ACTION ON ISSUE
250641,Logging broken for GettingStarted (page-save-success logged as page-impression),"Change 71575 had a related patch set uploaded by Spage:
postEdit module needs to run before openTask

https://gerrit.wikimedia.org/r/71575",task_subcomment,"Change 71575 had a related patch set uploaded by Spage:
postEdit module needs to run before openTask

GERRIT_URL",TASK PROGRESS
250637,Logging broken for GettingStarted (page-save-success logged as page-impression),"GettingStarted only logs page-save-success if wgPostEdit is true. On my local wiki I printed log messages from the two routines, and they sometimes came out:
   about to log returnto page-impression
   postEdit.js set wgPostEdit true!

So the postEdit.js is running *after* openTask.js and that's why the wrong event is logged. On enwiki with resourceLoaderDebug cookie it did log a page-save-success event (go look at GettingStartedNavbar_5588671 where event_userId = 19275523), but without the RL debug in regular operation GS logs page-impression.

RL loads postEdit first in its mw.loader.load() call at the end of the page body, but I don't know what RL's guarantee of code execution ordering is.

Adding a dependency to ext.gettingstarted.openTask:
        'mediawiki.action.view.postEdit', // need this to run prior

seemed to fix it locally; another fix would be to use 
        mw.hook( 'postEdit' ).add( function ()
as VE does instead of changing the action from page-impression to page-save-success.

I don't know how VE affects this, this was all clicking [Edit source].",task_subcomment,"GettingStarted only logs page-save-success if wgPostEdit is true. On my local wiki I printed log messages from the two routines, and they sometimes came out:
   about to log returnto page-impression
   postEdit.js set wgPostEdit true!

So the postEdit.js is running *after* openTask.js and that's why the wrong event is logged. On enwiki with resourceLoaderDebug cookie it did log a page-save-success event (go look at GettingStartedNavbar_5588671 where event_userId = 19275523), but without the RL debug in regular operation GS logs page-impression.

RL loads postEdit first in its mw.loader.load() call at the end of the page body, but I don't know what RL's guarantee of code execution ordering is.

Adding a dependency to ext.gettingstarted.openTask:
        'mediawiki.action.view.postEdit', // need this to run prior

seemed to fix it locally; another fix would be to use 
        mw.hook( 'postEdit' ).add( function ()
as VE does instead of changing the action from page-impression to page-save-success.

I don't know how VE affects this, this was all clicking [Edit source].",SOLUTION DISCUSSION
250632,Logging broken for GettingStarted (page-save-success logged as page-impression),"**swalling** wrote:

(In reply to comment #1)
> The latest GettingStartedNavbar table is GettingStartedNavbar_5588671
> (easiest
> way to see is SHOW TABLES).
> 
> However, that doesn't convincingly explain why the latest (by timestamp)
> enwiki
> entries in GettingStartedNavbar_5496876 are a long string of
> page-save-attempt
> (the last of which is on 2013-06-26), but the latest page-save-success is
> 2013-06-06.
> 
> It could be a coincidence, but it's worth looking into.

Okay, you were correct, this is worth looking in to. In the most recent logs (GettingStartedNavbar_5588671) it seems we are not logging any page-save-success events for the returnto funnel. Logging for other events in the returnto funnel seem normal, and page saves all gettingstarted funnels (copyedit, clarify, addlinks) are normal.",task_subcomment,"**swalling** wrote:

(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Okay, you were correct, this is worth looking in to. In the most recent logs (GettingStartedNavbar_5588671) it seems we are not logging any page-save-success events for the returnto funnel. Logging for other events in the returnto funnel seem normal, and page saves all gettingstarted funnels (copyedit, clarify, addlinks) are normal.",SOLUTION DISCUSSION
250627,Logging broken for GettingStarted (page-save-success logged as page-impression),"**swalling** wrote:

(In reply to comment #1)
> The latest GettingStartedNavbar table is GettingStartedNavbar_5588671
> (easiest
> way to see is SHOW TABLES).
> 

Resolving as not a bug, accordingly, because there's no RESOLVED STEVENISDUMB. ;)",task_subcomment,"**swalling** wrote:

(In reply to comment #1)
QUOTE
QUOTE
QUOTE
QUOTE

Resolving as not a bug, accordingly, because there's no RESOLVED STEVENISDUMB. ;)",ACTION ON ISSUE
250622,Logging broken for GettingStarted (page-save-success logged as page-impression),"The latest GettingStartedNavbar table is GettingStartedNavbar_5588671 (easiest way to see is SHOW TABLES).

However, that doesn't convincingly explain why the latest (by timestamp) enwiki entries in GettingStartedNavbar_5496876 are a long string of page-save-attempt (the last of which is on 2013-06-26), but the latest page-save-success is 2013-06-06.

It could be a coincidence, but it's worth looking into.",task_subcomment,"The latest GettingStartedNavbar table is GettingStartedNavbar_5588671 (easiest way to see is SHOW TABLES).

However, that doesn't convincingly explain why the latest (by timestamp) enwiki entries in GettingStartedNavbar_5496876 are a long string of page-save-attempt (the last of which is on 2013-06-26), but the latest page-save-success is 2013-06-06.

It could be a coincidence, but it's worth looking into.",MOTIVATION
52181,VisualEditor: weird behaviour on reload following save (JS not loading?),"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",task_description,"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",BUG REPRODUCTION
249455,VisualEditor: weird behaviour on reload following save (JS not loading?),"Yeah, sorry about this bug, and my tardiness in replying; this was bug 49620, which we fixed just before you posted this, but only deployed the next day.

*** This bug has been marked as a duplicate of bug 49620 ***",task_subcomment,"Yeah, sorry about this bug, and my tardiness in replying; this was bug 49620, which we fixed just before you posted this, but only deployed the next day.

*** This bug has been marked as a duplicate of bug 49620 ***",ACTION ON ISSUE
52168,VisualEditor: Odd behavior using arrow keys for cursor movement,"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",task_description,"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:

URL

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
248776,VisualEditor: Odd behavior using arrow keys for cursor movement,"This is a duplicate of bug 48847, which we fixed last week; sorry for not getting to this bug until now.

*** This bug has been marked as a duplicate of bug 48847 ***",task_subcomment,"This is a duplicate of bug 48847, which we fixed last week; sorry for not getting to this bug until now.

*** This bug has been marked as a duplicate of bug 48847 ***",ACTION ON ISSUE
52147," tags added to (valid) list in a template parameter, corrupting them","In general,

{{foo
bar = 
* 1
* 2
* 3
}}

… is RT'ing to 

{{foo
bar = * 1
* 2
* 3
}}

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",task_description,"In general,

{{foo
bar = 
* 1
* 2
* 3
}}

… is RT'ing to 

{{foo
bar = * 1
* 2
* 3
}}

Examples: 

* URL
* URL

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**:
URL",SOLUTION USAGE
247575," tags added to (valid) list in a template parameter, corrupting them","

*** This bug has been marked as a duplicate of bug 50144 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50144 ***",ACTION ON ISSUE
52143,Missing root git config file when cloning,"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",task_description,"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 URL /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",BUG REPRODUCTION
247419,Missing root git config file when cloning,[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.],task_subcomment,[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.],ACTION ON ISSUE
247414,Missing root git config file when cloning,"As of git 1.8.1.1 and above, if the home directory can't be accessed, it results in a fatal error. That was the cause of the error. I fixed it in gerrit change 71165.",task_subcomment,"As of git 1.8.1.1 and above, if the home directory can't be accessed, it results in a fatal error. That was the cause of the error. I fixed it in gerrit change 71165.",BUG REPRODUCTION
247409,Missing root git config file when cloning,"Change 71165 had a related patch set uploaded by Ori.livneh:
Set $HOME when git-cloning

https://gerrit.wikimedia.org/r/71165",task_subcomment,"Change 71165 had a related patch set uploaded by Ori.livneh:
Set $HOME when git-cloning

GERRIT_URL",ACTION ON ISSUE
247403,Missing root git config file when cloning,"Happens to me too. I did `git pull --ff-only` on my host, added ""include role::visualeditor"" to puppet/manifests/site.pp, and tried to run vagrant for the first time in weeks. I tried vagrant up, vagrant reload, and vagrant provision, and all failed early on with variations of the same error as above:

[default] Running provisioner: puppet...
Running Puppet with site.pp...
info: Applying configuration version '1372472629'
notice: /Stage[main]/Role::Visualeditor/Mediawiki::Extension[VisualEditor]/Git::Clone[mediawiki/extensions/VisualEditor]/Exec[git clone mediawiki/extensions/VisualEditor]/returns: fatal: unable to access '/root/.config/git/config': Permission denied

I can `vagrant ssh` and the wiki is running on http://127.0.0.1:8080/ , but Special:Version says I don't have VisualEditor installed. I'm running Ubuntu 13.04.",task_subcomment,"Happens to me too. I did CODE on my host, added ""include role::visualeditor"" to puppet/manifests/site.pp, and tried to run vagrant for the first time in weeks. I tried vagrant up, vagrant reload, and vagrant provision, and all failed early on with variations of the same error as above:

[default] Running provisioner: puppet...
Running Puppet with site.pp...
info: Applying configuration version '1372472629'
notice: /Stage[main]/Role::Visualeditor/Mediawiki::Extension[VisualEditor]/Git::Clone[mediawiki/extensions/VisualEditor]/Exec[git clone mediawiki/extensions/VisualEditor]/returns: fatal: unable to access '/root/.config/git/config': Permission denied

I can CODE and the wiki is running on URL , but Special:Version says I don't have VisualEditor installed. I'm running Ubuntu 13.04.",BUG REPRODUCTION
52142,"Images: Frameless images should not emit the ""caption"" as a 
                 even when it's set","[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 
                 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 
                s for these as part of bug 50113, but Parsoid should fix these in due course.

--------------------------
**Version**: unspecified
**Severity**: minor",task_description,"[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 
                 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 
                s for these as part of bug 50113, but Parsoid should fix these in due course.

--------------------------
**Version**: unspecified
**Severity**: minor",BUG REPRODUCTION
247370,"Images: Frameless images should not emit the ""caption"" as a 
                 even when it's set",[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
247366,"Images: Frameless images should not emit the ""caption"" as a 
                 even when it's set",This is by design. See http://www.mediawiki.org/wiki/Parsoid/MediaWiki_DOM_spec#Images for documentation and rationales.,task_subcomment,This is by design. See URL for documentation and rationales.,SOLUTION DISCUSSION
52116,VisualEditor adding spurious pipe separators to image syntax,"https://en.wikipedia.org/w/index.php?title=History_of_Delta_Air_Lines&curid=38607247&diff=561387547&oldid=557734729

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
245599,VisualEditor adding spurious pipe separators to image syntax,"

*** This bug has been marked as a duplicate of bug 50012 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50012 ***",ACTION ON ISSUE
245594,VisualEditor adding spurious pipe separators to image syntax,"[[File:Delta logo.svg|right|200px]] --> [[File:Delta logo.svg|right|200px|]]

I've seen this in a few other diffs as well.",task_subcomment,"[[File:Delta logo.svg|right|200px]] --> [[File:Delta logo.svg|right|200px|]]

I've seen this in a few other diffs as well.",SOLUTION USAGE
52108,VisualEditor template parameter normalization results in dirty diffs,"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{{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}}

to...

* Winner, Magenta Foundation award{{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}}

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"URL

The change should have only italicized a few publication names. Instead it changed...

* Winner, Magenta Foundation award{{cite book |last= Pritchard | first= Lisa |authorlink= Lisa Pritchard|title= Setting Up a Successful Photography Business: How to be a Professional Photographer |url= URL 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}}

to...

* Winner, Magenta Foundation award{{cite book |last=Pritchard | first=Lisa |authorlink=Lisa Pritchard|title=Setting Up a Successful Photography Business: How to be a Professional Photographer |url=URL 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}}

--------------------------
**Version**: unspecified
**Severity**: normal",INVESTIGATION AND EXPLORATION
245113,VisualEditor template parameter normalization results in dirty diffs,"Closing ""bugs"" which consist of multiple issues.",task_subcomment,"Closing ""bugs"" which consist of multiple issues.",ACTION ON ISSUE
245110,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Save_Rock_and_Roll&curid=38419944&diff=561416388&oldid=561387755,task_subcomment,URL,ACTION ON ISSUE
245105,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Ivan_Tan&curid=39767321&diff=561408770&oldid=561406619,task_subcomment,URL,ACTION ON ISSUE
245101,VisualEditor template parameter normalization results in dirty diffs,"(In reply to comment #9)
> This remains a duplicate of bug 50066; that is merged on VE end. There are
> some artefacts due to Parsoid which are different bugs (which are also fixed
> and being deployed this afternoon, hopefully) [...]

Let's do this: mark this bug as resolved when it's actually resolved. Not when it may be hopefully resolved in the future.",task_subcomment,"(In reply to comment #9)
QUOTE
QUOTE
QUOTE

Let's do this: mark this bug as resolved when it's actually resolved. Not when it may be hopefully resolved in the future.",ACTION ON ISSUE
245096,VisualEditor template parameter normalization results in dirty diffs,"https://en.wikipedia.org/w/index.php?title=United_States_presidential_election,_1844&curid=40514&diff=561407211&oldid=559883253",task_subcomment,URL,ACTION ON ISSUE
245093,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Sela_(Saudi_Arabia)&curid=26371208&diff=561403748&oldid=561269241,task_subcomment,URL,ACTION ON ISSUE
245090,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Kamelot&curid=1161493&diff=561402036&oldid=560661945,task_subcomment,URL,ACTION ON ISSUE
245086,VisualEditor template parameter normalization results in dirty diffs,"This remains a duplicate of bug 50066; that is merged on VE end. There are some artefacts due to Parsoid which are different bugs (which are also fixed and being deployed this afternoon, hopefully), but Bugzilla doesn't have ""dupe of these seven bugs"" as an option.

*** This bug has been marked as a duplicate of bug 50066 ***",task_subcomment,"This remains a duplicate of bug 50066; that is merged on VE end. There are some artefacts due to Parsoid which are different bugs (which are also fixed and being deployed this afternoon, hopefully), but Bugzilla doesn't have ""dupe of these seven bugs"" as an option.

*** This bug has been marked as a duplicate of bug 50066 ***",ACTION ON ISSUE
245082,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=19th_Virginia_Infantry&curid=25759369&diff=561398799&oldid=561398641,task_subcomment,URL,ACTION ON ISSUE
245079,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Dan_Penteado&curid=13006822&diff=561396894&oldid=561392351,task_subcomment,URL,ACTION ON ISSUE
245076,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Low_Orbit_Ion_Cannon&curid=28240388&diff=561396775&oldid=560499820,task_subcomment,URL,ACTION ON ISSUE
245071,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=MTV&curid=18856&diff=561395466&oldid=561389102,task_subcomment,URL,ACTION ON ISSUE
245068,VisualEditor template parameter normalization results in dirty diffs,"https://en.wikipedia.org/w/index.php?title=Wappingers_Falls,_New_York&curid=126391&diff=561394799&oldid=561394670",task_subcomment,URL,ACTION ON ISSUE
245063,VisualEditor template parameter normalization results in dirty diffs,https://en.wikipedia.org/w/index.php?title=Wild_Pack&curid=29143457&diff=561394555&oldid=561394449,task_subcomment,URL,ACTION ON ISSUE
245059,VisualEditor template parameter normalization results in dirty diffs,"Re-opening this for now. This doesn't appear to be fixed:

https://en.wikipedia.org/w/index.php?title=Paul_Evans_(footballer_born_1973)&curid=15575267&diff=561390930&oldid=561390588",task_subcomment,"Re-opening this for now. This doesn't appear to be fixed:

URL",BUG REPRODUCTION
245057,VisualEditor template parameter normalization results in dirty diffs,"

*** This bug has been marked as a duplicate of bug 50066 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50066 ***",ACTION ON ISSUE
52106,VisualEditor ref weirdness,"https://en.wikipedia.org/w/index.php?title=Laura_Pannack&diff=561336738&oldid=557984097

 --> 

Weird.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"URL

 --> 

Weird.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244928,VisualEditor ref weirdness,https://en.wikipedia.org/w/index.php?title=Save_Rock_and_Roll&curid=38419944&diff=561416388&oldid=561387755,task_subcomment,URL,ACTION ON ISSUE
244922,VisualEditor ref weirdness,https://en.wikipedia.org/w/index.php?title=Daniel_Kahneman&curid=165492&diff=561411461&oldid=560179630,task_subcomment,URL,ACTION ON ISSUE
244916,VisualEditor ref weirdness,"

*** This bug has been marked as a duplicate of bug 50066 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50066 ***",ACTION ON ISSUE
52101,VisualEditor spurious attribute normalization (resulting in dirty diffs),"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",task_description,"URL

URL

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244653,VisualEditor spurious attribute normalization (resulting in dirty diffs),"Closing ""bugs"" which consist of multiple issues.",task_subcomment,"Closing ""bugs"" which consist of multiple issues.",ACTION ON ISSUE
244648,VisualEditor spurious attribute normalization (resulting in dirty diffs),"This is still happening:

https://en.wikipedia.org/w/index.php?title=Wappingers_Falls,_New_York&curid=126391&diff=561392322&oldid=560081821",task_subcomment,"This is still happening:

URL",BUG REPRODUCTION
244641,VisualEditor spurious attribute normalization (resulting in dirty diffs),"

*** This bug has been marked as a duplicate of bug 50066 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50066 ***",ACTION ON ISSUE
52099,VisualEditor dirty diff,"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",task_description,"URL

I did a section edit to link ""Food Network"". This was the resulting diff.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
244489,VisualEditor dirty diff,"Sorry about this; fixed by bug 50066 which we'll deploy in a few minutes.

*** This bug has been marked as a duplicate of bug 50066 ***",task_subcomment,"Sorry about this; fixed by bug 50066 which we'll deploy in a few minutes.

*** This bug has been marked as a duplicate of bug 50066 ***",ACTION ON ISSUE
52086,VisualEditor: Impossible to review or save changes in IE10,"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
Projects:
  mediawiki/extensions/VisualEditor
     ^master$
  operations/mediawiki-config
     ^master$ 
  test/mediawiki
    
  analytics/wikistats
    
  analytics/udp-filters
    
  operations/puppet
    
  analytics/webstatscollector
    
  analytics/libanon
    
  mediawiki/extensions/Parsoid
    
  mediawiki/core
     (?!REL1_19)^(\.jshint|.*\.(js|json)$)
    
     ^(REL1_21|master)$^.*\.(js|json)$
     ^master$
     ^REL1_19$
     ^REL1_20$
     ^REL1_21
    
       
  mediawiki/extensions/Math
    
  integration/docroot
     ^master$

Some of those jobs are shared with over pipelines (such as mediawiki-core-lint) and are thus meaningless.  The only candidates would be:


mwext-VisualEditor-doc-publish
beta-mediawiki-config-update
beta-recompile-math-texvc
test-mediawiki-docgen
operations-puppet-doc
parsoid-regressions
mediawiki-core-regression-*
integration-docroot-deploy


If we wanted to do that for other repositories (such as mediawiki extensions), we will need to have JJB to create a new job and edit the Zuul template 'extensions-unittests' to have a postmerge pipeline.


 I need to restart Jenkins next week, so I will look at installing the plugin.",task_subcomment,"As Timo said, this will only be useful for Jobs triggering only on merge events. In Zuul that is the 'postmerge' pipeline, its configuration is currently:


Configured Pipeline Manager postmerge
Events:
  
Projects:
  mediawiki/extensions/VisualEditor
     ^master$
  operations/mediawiki-config
     ^master$ 
  test/mediawiki
    
  analytics/wikistats
    
  analytics/udp-filters
    
  operations/puppet
    
  analytics/webstatscollector
    
  analytics/libanon
    
  mediawiki/extensions/Parsoid
    
  mediawiki/core
     (?!REL1_19)^(\.jshint|.*\.(js|json)$)
    
     ^(REL1_21|master)$^.*\.(js|json)$
     ^master$
     ^REL1_19$
     ^REL1_20$
     ^REL1_21
    
       
  mediawiki/extensions/Math
    
  integration/docroot
     ^master$

Some of those jobs are shared with over pipelines (such as mediawiki-core-lint) and are thus meaningless.  The only candidates would be:


mwext-VisualEditor-doc-publish
beta-mediawiki-config-update
beta-recompile-math-texvc
test-mediawiki-docgen
operations-puppet-doc
parsoid-regressions
mediawiki-core-regression-*
integration-docroot-deploy


If we wanted to do that for other repositories (such as mediawiki extensions), we will need to have JJB to create a new job and edit the Zuul template 'extensions-unittests' to have a postmerge pipeline.


 I need to restart Jenkins next week, so I will look at installing the plugin.",SOLUTION DISCUSSION
239941,Jenkins: Provide build status images,"Note that due to the way we currently separate larger build steps into separate jobs, you'd need to display about a dozen status badges to have the complete picture (e.g. mediawiki-core-lint, mediawiki-core-jslint, mediawiki-core-phpunit-groupA, mediawiki-core-phpunit-groupB, mediawiki-core-databaseless etc.).


If we do want to display this somewhere (for the unlikely event that someone bypassed Jenkins), we would need to have a post-merge job that runs on master only (so that it isn't affected by failing tests from proposed changes in Gerrit).

The closest we have for that is the post-merge job for phpunit regressions:

https://integration.wikimedia.org/ci/view/MediaWiki/job/mediawiki-core-regression-master/

This one only runs for master and only post-merge.

Note though that this doesn't include phplint, jshint and qunit. Only phpunit.",task_subcomment,"Note that due to the way we currently separate larger build steps into separate jobs, you'd need to display about a dozen status badges to have the complete picture (e.g. mediawiki-core-lint, mediawiki-core-jslint, mediawiki-core-phpunit-groupA, mediawiki-core-phpunit-groupB, mediawiki-core-databaseless etc.).


If we do want to display this somewhere (for the unlikely event that someone bypassed Jenkins), we would need to have a post-merge job that runs on master only (so that it isn't affected by failing tests from proposed changes in Gerrit).

The closest we have for that is the post-merge job for phpunit regressions:

URL

This one only runs for master and only post-merge.

Note though that this doesn't include phplint, jshint and qunit. Only phpunit.",SOLUTION DISCUSSION
239931,Jenkins: Provide build status images,"Installing that plugin won't be very useful because we use Jenkins pre-merge, not post-merge.

The builds you see in Jenkins are for patch sets in Gerrit. The latest build of those jobs have no meaning in correlation to the state of a repository as those builds are just an arbitrary sequence of builds on proposed changes.

The build status of our branches (incl. master) is always passing because you can't merge a change if it would result in the build failing.

Thus we don't need a status badge because our workflow (unlike most typical projects with e.g. Travis-CI set up on GitHub) makes it impossible not to be passing because we force every change to be pushed for review first, and is only merged after it is Verified by a passing build[1].

[1] Unless someone with the appropriate user permissions bypasses Jenkins manually, which is frowned upon and would break Jenkins for every submitted patch set after that.",task_subcomment,"Installing that plugin won't be very useful because we use Jenkins pre-merge, not post-merge.

The builds you see in Jenkins are for patch sets in Gerrit. The latest build of those jobs have no meaning in correlation to the state of a repository as those builds are just an arbitrary sequence of builds on proposed changes.

The build status of our branches (incl. master) is always passing because you can't merge a change if it would result in the build failing.

Thus we don't need a status badge because our workflow (unlike most typical projects with e.g. Travis-CI set up on GitHub) makes it impossible not to be passing because we force every change to be pushed for review first, and is only merged after it is Verified by a passing build[1].

[1] Unless someone with the appropriate user permissions bypasses Jenkins manually, which is frowned upon and would break Jenkins for every submitted patch set after that.",SOLUTION USAGE
52019,Parametr adds =,"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",task_description,"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: URL

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
239811,Parametr adds =,"But anyway, thx for explanation and sorry for disturbing!",task_subcomment,"But anyway, thx for explanation and sorry for disturbing!",SOCIAL CONVERSATION
239806,Parametr adds =,"(In reply to comment #1)
> ...the parameter name in this case is ""1""...

Isnt this tricky? How the newbie should know, that ""parametr name is 1""?",task_subcomment,"(In reply to comment #1)
QUOTE

Isnt this tricky? How the newbie should know, that ""parametr name is 1""?",SOLUTION DISCUSSION
239800,Parametr adds =,"This was caused by you adding ""Saint Robert of Molesme"" as the parameter name rather than value - the parameter name in this case is ""1"", which wikitext can hide (the formal wikitext you were intending to add was ""{{Commonscat|1=Saint Robert of Molesme}}"".

In English the label () is ""Parameter name"", which I believe is shown as ""Jméno parametru"" in Czech. I think the addition of the help documentation at https://www.mediawiki.org/wiki/Help:VisualEditor/User_guide and linked from the help menu in the interface will reduce this occurring, but sorry for the confusion in the first place. :-(",task_subcomment,"This was caused by you adding ""Saint Robert of Molesme"" as the parameter name rather than value - the parameter name in this case is ""1"", which wikitext can hide (the formal wikitext you were intending to add was ""{{Commonscat|1=Saint Robert of Molesme}}"".

In English the label () is ""Parameter name"", which I believe is shown as ""Jméno parametru"" in Czech. I think the addition of the help documentation at URL and linked from the help menu in the interface will reduce this occurring, but sorry for the confusion in the first place. :-(",ACTION ON ISSUE
52016,Uncaught TypeError: Cannot read property 'description' of undefined,"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",task_description,"After loading the Visual Editor on
URL
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:
URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
239680,Uncaught TypeError: Cannot read property 'description' of undefined,"This is the same as bug 49493 which is fixed in master and now in production; sorry for the disruption.

*** This bug has been marked as a duplicate of bug 49493 ***",task_subcomment,"This is the same as bug 49493 which is fixed in master and now in production; sorry for the disruption.

*** This bug has been marked as a duplicate of bug 49493 ***",ACTION ON ISSUE
51986,Provide ability to alternate between visual and source editing,"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",task_description,"A user suggested at
URL
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",SOLUTION DISCUSSION
237997,Provide ability to alternate between visual and source editing,"Already suggested as bug 47779.

*** This bug has been marked as a duplicate of bug 47779 ***",task_subcomment,"Already suggested as bug 47779.

*** This bug has been marked as a duplicate of bug 47779 ***",BUG REPRODUCTION
51984,VisualEditor: Insecure image links on https,"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",task_description,"When I open
URL
I see several warnings like this on Google Chrome:

The page at URL displayed insecure content from URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
237865,VisualEditor: Insecure image links on https,"

*** This bug has been marked as a duplicate of bug 43015 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 43015 ***",ACTION ON ISSUE
51960,VisualEditor: not functioning on it.wiki,"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}",task_description,"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}",BUG REPRODUCTION
236220,VisualEditor: not functioning on it.wiki,"Cool; marking as resolved. I'd suggest speaking to the QE author quickfast, then :D.",task_subcomment,"Cool; marking as resolved. I'd suggest speaking to the QE author quickfast, then :D.",SOLUTION USAGE
236215,VisualEditor: not functioning on it.wiki,"Confirming it's QE's fault, http://it.wikipedia.org/w/index.php?title=Wikipedia%3AVisualEditor%2FCommenti&diff=59583884&oldid=59583801",task_subcomment,"Confirming it's QE's fault, URL",TASK PROGRESS
236212,VisualEditor: not functioning on it.wiki,"I need to point out that I'm testing gadgets I added, I'm pretty sure defaults are ok :) http://it.wikipedia.org/w/index.php?title=Utente%3AElitre_%28WMF%29%2FSandbox&diff=59583614&oldid=59581474 tells me QuickEdit might cause the trouble here, since I managed to edit with VE without it.",task_subcomment,"I need to point out that I'm testing gadgets I added, I'm pretty sure defaults are ok :) URL tells me QuickEdit might cause the trouble here, since I managed to edit with VE without it.",TASK PROGRESS
51950,Required 'Edit Source' at Sections,"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",task_description,"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",SOLUTION DISCUSSION
235627,Required 'Edit Source' at Sections,"This is a duplicate of bug 49666 which we hope to do very soon.

*** This bug has been marked as a duplicate of bug 49666 ***",task_subcomment,"This is a duplicate of bug 49666 which we hope to do very soon.

*** This bug has been marked as a duplicate of bug 49666 ***",ACTION ON ISSUE
51939,VisualEditor translates templates into Uzbek language,"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",task_description,"When I edit URL 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",BUG REPRODUCTION
235015,VisualEditor translates templates into Uzbek language,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
235007,VisualEditor translates templates into Uzbek language,"Caffeine-induced hallucination on the reporter's part would have been a better explanation.  Yes, 49411 again.

*** This bug has been marked as a duplicate of bug 49411 ***",task_subcomment,"Caffeine-induced hallucination on the reporter's part would have been a better explanation.  Yes, 49411 again.

*** This bug has been marked as a duplicate of bug 49411 ***",BUG REPRODUCTION
235001,VisualEditor translates templates into Uzbek language,Looks like a Parsoid caching issue: bug 49411 again?,task_subcomment,Looks like a Parsoid caching issue: bug 49411 again?,BUG REPRODUCTION
51919,"VisualEditor: Internal wiki link using ""pipe trick"" [[/Foo/]] to link to sub page broken","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}",task_description,"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}",BUG REPRODUCTION
233418,"VisualEditor: Internal wiki link using ""pipe trick"" [[/Foo/]] to link to sub page broken","

*** This bug has been marked as a duplicate of bug 48081 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 48081 ***",ACTION ON ISSUE
51891,Parsoid: full sized images are displayed regardless of a |pictured parameter,"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",task_description,"In particular it appears that the |pictured parameter in a file link is not being recognised. Take a look at URL in the VisualEditor.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
231505,Parsoid: full sized images are displayed regardless of a |pictured parameter,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
231499,Parsoid: full sized images are displayed regardless of a |pictured parameter,"This is a dupe of bug 48387 which is fixed and deployed as of a few minutes ago but Parsoid's cache needs to be purged for this to show up.

*** This bug has been marked as a duplicate of bug 48387 ***",task_subcomment,"This is a dupe of bug 48387 which is fixed and deployed as of a few minutes ago but Parsoid's cache needs to be purged for this to show up.

*** This bug has been marked as a duplicate of bug 48387 ***",ACTION ON ISSUE
231493,Parsoid: full sized images are displayed regardless of a |pictured parameter,"Aha,",task_subcomment,"Aha,",ACTION ON ISSUE
231488,Parsoid: full sized images are displayed regardless of a |pictured parameter,"No, it's the : in front of the Image:name, that isn't being recognized.",task_subcomment,"No, it's the : in front of the Image:name, that isn't being recognized.",BUG REPRODUCTION
51877,VisualEditor: Pawn ♙ appears when bolding multiple list items at same time,"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",task_description,"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",BUG REPRODUCTION
230629,VisualEditor: Pawn ♙ appears when bolding multiple list items at same time,"Dupe of bug 49732 which is fixed in master and wmf8; will get that pushed to production wmf7 tonight.

*** This bug has been marked as a duplicate of bug 49732 ***",task_subcomment,"Dupe of bug 49732 which is fixed in master and wmf8; will get that pushed to production wmf7 tonight.

*** This bug has been marked as a duplicate of bug 49732 ***",ACTION ON ISSUE
51824,Existing image inclusions are duplicated and truncated by VisualEditor,"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",task_description,"In the following edits, images that were already in the article were duplicated on save, and the duplicate was truncated:

URL
URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
252856,Existing image inclusions are duplicated and truncated by VisualEditor,"This is 49729.

*** This bug has been marked as a duplicate of bug 49729 ***",task_subcomment,"This is 49729.

*** This bug has been marked as a duplicate of bug 49729 ***",ACTION ON ISSUE
252852,Existing image inclusions are duplicated and truncated by VisualEditor,"(sorry, just saw the first edit.)",task_subcomment,"(sorry, just saw the first edit.)",ACTION ON ISSUE
252845,Existing image inclusions are duplicated and truncated by VisualEditor,One more: https://www.mediawiki.org/w/index.php?title=VisualEditor%2FFAQ&diff=713663&oldid=713655,task_subcomment,One more: URL,ACTION ON ISSUE
51810,Parsoid cannot parse some wikimarkup,"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",task_description,"See URL

In the VE: URL
In the normal, rendered page: URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
251855,Parsoid cannot parse some wikimarkup,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
251846,Parsoid cannot parse some wikimarkup,"Note that the use of HTML comments mid-token was WONTFIXed: bug 49750.

*** This bug has been marked as a duplicate of bug 49753 ***",task_subcomment,"Note that the use of HTML comments mid-token was WONTFIXed: bug 49750.

*** This bug has been marked as a duplicate of bug 49753 ***",ACTION ON ISSUE
51802,VisualEditor: IE8 support,"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",task_description,"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",FUTURE PLAN
251182,VisualEditor: IE8 support,Great! Thanks.,task_subcomment,Great! Thanks.,SOLUTION USAGE
251178,VisualEditor: IE8 support,"(In reply to comment #4)
> Makes a lot of sense. Any specific technologies that are problematic? Just
> so I can avoid coming off as ""we're not doing it, it's hard"".

Primary technologies:
* HTML 5, most notably with ContentEditable (IE8 has basic support; IE in general has major issues with elements that aren't editable inside ones that are - e.g. templates inside pages - though we've found a way to hack around it in IE9&10 for now)
* Javascript (ECMAScript) 5 (not all of it, which is good as IE9 doesn't do that either, but more than IE8 supports)
* Selection interaction (IE's support is... Quixotic, to be polite)
* Key detection/over-riding (same as for selection)",task_subcomment,"(In reply to comment #4)
QUOTE
QUOTE

Primary technologies:
* HTML 5, most notably with ContentEditable (IE8 has basic support; IE in general has major issues with elements that aren't editable inside ones that are - e.g. templates inside pages - though we've found a way to hack around it in IE9&10 for now)
* Javascript (ECMAScript) 5 (not all of it, which is good as IE9 doesn't do that either, but more than IE8 supports)
* Selection interaction (IE's support is... Quixotic, to be polite)
* Key detection/over-riding (same as for selection)",SOLUTION DISCUSSION
251175,VisualEditor: IE8 support,"Makes a lot of sense. Any specific technologies that are problematic? Just so I can avoid coming off as ""we're not doing it, it's hard"".",task_subcomment,"Makes a lot of sense. Any specific technologies that are problematic? Just so I can avoid coming off as ""we're not doing it, it's hard"".",SOLUTION DISCUSSION
251169,VisualEditor: IE8 support,"This is a WONTFIX; Internet Explorer in general doesn't support many of the key technologies that VisualEditor relies upon, and this becomes more acute the further back from IE10 you get.

Supporting ""just"" IE9 and IE10 has been approximately 90% of our browser-specific workload; for IE8 support, we would need to write an entirely parallel implementation of VisualEditor just for that (and even then, most things wouldn't work).

We cannot justify spending a very significant amount of donors' funds on IE8, which is (as of May) less than 5% of all our readers, and likely even less than that for editors. See [[mw:VisualEditor/Target browser matrix]] (which needs to be updated) for detail about which browsers we actively support.",task_subcomment,"This is a WONTFIX; Internet Explorer in general doesn't support many of the key technologies that VisualEditor relies upon, and this becomes more acute the further back from IE10 you get.

Supporting ""just"" IE9 and IE10 has been approximately 90% of our browser-specific workload; for IE8 support, we would need to write an entirely parallel implementation of VisualEditor just for that (and even then, most things wouldn't work).

We cannot justify spending a very significant amount of donors' funds on IE8, which is (as of May) less than 5% of all our readers, and likely even less than that for editors. See [[mw:VisualEditor/Target browser matrix]] (which needs to be updated) for detail about which browsers we actively support.",SOLUTION USAGE
251164,VisualEditor: IE8 support,That's an en_INTERNET idiom. Do you want me to sic the internationalisation team on you? Cuz I will.,task_subcomment,That's an en_INTERNET idiom. Do you want me to sic the internationalisation team on you? Cuz I will.,SOCIAL CONVERSATION
251158,VisualEditor: IE8 support,Kill it with fire!,task_subcomment,Kill it with fire!,ACTION ON ISSUE
51795,VisualEditor: Insert media create link to undefined,"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",task_description,"URL

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",BUG REPRODUCTION
250757,VisualEditor: Insert media create link to undefined,"Same thing?

*** This bug has been marked as a duplicate of bug 49596 ***",task_subcomment,"Same thing?

*** This bug has been marked as a duplicate of bug 49596 ***",ACTION ON ISSUE
51768,VisualEditor: strange artefact in monobook when resizing images,"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}",task_description,"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}",BUG REPRODUCTION
249272,VisualEditor: strange artefact in monobook when resizing images,"This is a duplicate of bug 50074 (despite the naming, it was a wider issue with phantoms), which is now fixed.

*** This bug has been marked as a duplicate of bug 50074 ***",task_subcomment,"This is a duplicate of bug 50074 (despite the naming, it was a wider issue with phantoms), which is now fixed.

*** This bug has been marked as a duplicate of bug 50074 ***",ACTION ON ISSUE
51756,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","See (ferinstance) https://en.wikipedia.org/w/index.php?title=User:JohnCD/draft&diff=560430675&oldid=560430611

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See (ferinstance) URL

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
248519,"VisualEditor: VE providing unasked-for removal of ""duplicate"" formatting","

%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",task_subcomment,"

%%%*** This bug has been marked as a duplicate of bug 49755 ***%%%",ACTION ON ISSUE
51739,Parsoid uses nowiki tags for positional template parameters with '='s rather than just explicitly declaring them,"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|foo=bar|baz}}. However, ""foo=bar"" and ""foo=bar"" 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",task_description,"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|foo=bar|baz}}. However, ""foo=bar"" and ""foo=bar"" are not equivalent wikitext. For example, nowiki tags will break wikilinks.

There's an example of the difference in this diff:
URL

See the effects for the revisions before and after (look at the ""Inline template"" section).

Before: URL
After: URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
247573,Parsoid uses nowiki tags for positional template parameters with '='s rather than just explicitly declaring them,"Change 72876 merged by jenkins-bot:
Bug 49739: Use named parameter if value contains '='

https://gerrit.wikimedia.org/r/72876",task_subcomment,"Change 72876 merged by jenkins-bot:
Bug 49739: Use named parameter if value contains '='

GERRIT_URL",ACTION ON ISSUE
247568,Parsoid uses nowiki tags for positional template parameters with '='s rather than just explicitly declaring them,"Change 72876 had a related patch set uploaded by GWicke:
Bug 49739: Use named parameter if value contains '='

https://gerrit.wikimedia.org/r/72876",task_subcomment,"Change 72876 had a related patch set uploaded by GWicke:
Bug 49739: Use named parameter if value contains '='

GERRIT_URL",ACTION ON ISSUE
247564,Parsoid uses nowiki tags for positional template parameters with '='s rather than just explicitly declaring them,"This feels like a Parsoid bug, but I'm not sure? The user creating the equivalent of {{foo|1=foo|2=bar=foo}} should serialise to {{foo|foo|2=bar=foo}} instead of  {{foo|foo|bar=foo}}.",task_subcomment,"This feels like a Parsoid bug, but I'm not sure? The user creating the equivalent of {{foo|1=foo|2=bar=foo}} should serialise to {{foo|foo|2=bar=foo}} instead of  {{foo|foo|bar=foo}}.",BUG REPRODUCTION
247559,Parsoid uses nowiki tags for positional template parameters with '='s rather than just explicitly declaring them,See also bug 49743.,task_subcomment,See also bug 49743.,ACTION ON ISSUE
51730,VisualEditor: visual representation of template breaks on 'apply changes',"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}",task_description,"Screenshot

See associated screenshot. This was an attempt to include ""foo"" in a string-based parameter in the infobox on URL

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11624}",BUG REPRODUCTION
247136,VisualEditor: visual representation of template breaks on 'apply changes',"This is a dupe of bug 49854.

*** This bug has been marked as a duplicate of bug 49854 ***",task_subcomment,"This is a dupe of bug 49854.

*** This bug has been marked as a duplicate of bug 49854 ***",ACTION ON ISSUE
51728,Enable voting in VisualEditor product,"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",task_description,"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",SOLUTION USAGE
246940,Enable voting in VisualEditor product,"The voting system is worse than valueless; it has absolutely impact on prioritisation (we use judgement and actually talking to the community for that), which is bad enough, but it gives users the entirely-false expectation that we even notice, let alone act upon, their ""votes"".

The ""voting"" system should be removed from Wikimedia's Bugzilla instance for all products, but at the very least, I think it's dangerously disrespectful to our users - who can't be expected to know this works in practice - to add its rot to any more places.

Marking as WONTFIX.",task_subcomment,"The voting system is worse than valueless; it has absolutely impact on prioritisation (we use judgement and actually talking to the community for that), which is bad enough, but it gives users the entirely-false expectation that we even notice, let alone act upon, their ""votes"".

The ""voting"" system should be removed from Wikimedia's Bugzilla instance for all products, but at the very least, I think it's dangerously disrespectful to our users - who can't be expected to know this works in practice - to add its rot to any more places.

Marking as WONTFIX.",ACTION ON ISSUE
246937,Enable voting in VisualEditor product,"(In reply to comment #1)
> Voting is not for tracking a bug, voting is to express that you'd like to
> see a
> bug fixed. The CC field is for tracking a bug.

See some of the comments in bug 25321 and bug 28385...",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE
QUOTE

See some of the comments in bug 25321 and bug 28385...",SOLUTION DISCUSSION
246934,Enable voting in VisualEditor product,"Voting is not for tracking a bug, voting is to express that you'd like to see a bug fixed. The CC field is for tracking a bug.


It's correct that some products have it enabled, others have not.

In general (not a topic for this bug report), if voting is NOT used as an input channel for planning by developers (and hence part of the process to define priorities), it should be disabled.
I cannot make that decision for another team, hence CC'ing James.
My personal preference currently is to completely disable voting for above reasons (not used by management as one input channel to set priorities).",task_subcomment,"Voting is not for tracking a bug, voting is to express that you'd like to see a bug fixed. The CC field is for tracking a bug.


It's correct that some products have it enabled, others have not.

In general (not a topic for this bug report), if voting is NOT used as an input channel for planning by developers (and hence part of the process to define priorities), it should be disabled.
I cannot make that decision for another team, hence CC'ing James.
My personal preference currently is to completely disable voting for above reasons (not used by management as one input channel to set priorities).",SOLUTION DISCUSSION
51724,VisualEditor: Possible to insert empty DEFAULTSORT,"Go to .

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",task_description,"Go to 

--------------------------
**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",task_description,"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: , 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",task_description,"A user reported this edit
 at their end display it, confusing users","See https://en.wikipedia.org/wiki/Daryle_Singletary?veaction=edit - the first three (but strangely, not the last) discography tables.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See URL - the first three (but strangely, not the last) discography tables.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244543,"VisualEditor: Tables with a faulty
    got added automatically. Where's that ""partial serialization"" mentioned before? -------------------------- **Version**: unspecified **Severity**: normal",task_description,"URL All change done manually is the insertion of ""编辑器测试"" at the first diff, then those extra and got added automatically. Where's that ""partial serialization"" mentioned before? -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 213878,VisualEditor: Extra tags got inserted causing infobox layout to be broken,"The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). Marking as a dupe. *** This bug has been marked as a duplicate of bug 47737 ***",task_subcomment,"The main part of this bug (the extra and ) look like they're duplicates of bug 47737 - this is fixed, but the new code won't get to zhwiki until 8 May. The whitespace changes look to be bug 47712 in Parsoid (but possibly actually a fault in VisualEditor). Marking as a dupe. *** This bug has been marked as a duplicate of bug 47737 ***",ACTION ON ISSUE 49816,VisualEditor: Unread message notification will not mark itself read,"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",task_description,"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",BUG REPRODUCTION 211213,VisualEditor: Unread message notification will not mark itself read,"(In reply to comment #0) > 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! The notices are urgent notifications about the page, not about the user. They're intended to always display, just like the editnotices they replace. Theoretically we could have per-user nullification of these, but that'd be messy. Another idea (perhaps?) is to not auto-display the OMG-this-is-so-important-all-users-must-acknowledge nature of editnotices and the like. However, this seems to fly against the underlying purpose of the notices. Marking as WONTFIX.",task_subcomment,"(In reply to comment #0) QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE QUOTE The notices are urgent notifications about the page, not about the user. They're intended to always display, just like the editnotices they replace. Theoretically we could have per-user nullification of these, but that'd be messy. Another idea (perhaps?) is to not auto-display the OMG-this-is-so-important-all-users-must-acknowledge nature of editnotices and the like. However, this seems to fly against the underlying purpose of the notices. Marking as WONTFIX.",ACTION ON ISSUE 49814,RTL Support for VisualEditor,"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",task_description,"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: URL -------------------------- **Version**: unspecified **Severity**: normal",FUTURE PLAN 211126,RTL Support for VisualEditor,"This is indeed a duplicate of bug 33126. mooeypoo please update your proposal linking to that bug. No worries, these things happen to veteran bug submitters as well. :) *** This bug has been marked as a duplicate of bug 33126 ***",task_subcomment,"This is indeed a duplicate of bug 33126. mooeypoo please update your proposal linking to that bug. No worries, these things happen to veteran bug submitters as well. :) *** This bug has been marked as a duplicate of bug 33126 ***",ACTION ON ISSUE 211122,RTL Support for VisualEditor,"I'll tentatively reopen it and mark it as blocking 33126 instead. Not sure though, maybe James knows. :)",task_subcomment,"I'll tentatively reopen it and mark it as blocking 33126 instead. Not sure though, maybe James knows. :)",ACTION ON ISSUE 211118,RTL Support for VisualEditor,It's a bug for tracking a GSoC proposal. I think that it should be reopened.,task_subcomment,It's a bug for tracking a GSoC proposal. I think that it should be reopened.,ISSUE CONTENT MANAGEMENT 211113,RTL Support for VisualEditor,"As this seems to be a tracking bug covering several aspects, marking as duplicate of bug 33126. Please see the list of specific issues blocking bug 33126 in the ""Depends on:"" section of bug 33126, and if some of the specific issues that you mention are not covered (means: do not have a bug report), please file separate bug reports for each item. Thanks! *** This bug has been marked as a duplicate of bug 33126 ***",task_subcomment,"As this seems to be a tracking bug covering several aspects, marking as duplicate of bug 33126. Please see the list of specific issues blocking bug 33126 in the ""Depends on:"" section of bug 33126, and if some of the specific issues that you mention are not covered (means: do not have a bug report), please file separate bug reports for each item. Thanks! *** This bug has been marked as a duplicate of bug 33126 ***",ACTION ON ISSUE 49768,[VisualEditor] CSS and JS pages should only be editable using the source editor,"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",task_description,"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",SOLUTION USAGE 207992,[VisualEditor] CSS and JS pages should only be editable using the source editor," *** This bug has been marked as a duplicate of bug 47456 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 47456 ***",ACTION ON ISSUE 49755,Feedback is broken,"**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",task_description,"**Author:** CODE **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: URL (35 seconds) The feedback is sent to URL 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",BUG REPRODUCTION 207265,Feedback is broken,"Not actually broken, see bug 42974.",task_subcomment,"Not actually broken, see bug 42974.",BUG REPRODUCTION 49751,A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page,"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",task_description,"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**: URL",BUG REPRODUCTION 233225,A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page,"Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",task_subcomment,"Confirm that this is intentional behaviour. There are a number of ways in which VisualEditor is deliberately not merely a WYSIWYG editor, and we should probably explain them so it's less confusing.",SOLUTION DISCUSSION 233217,A paragraph with multiple hash marks in the beginning is shown differently in VE and in output page,As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).,task_subcomment,As far as I know it is supposed to be that way - otherwise you wouldn't be able to add content to list item at each level. James - please confirm (and reopen if I'm wrong).,SOLUTION DISCUSSION 49546,VisualEditor: Adding a hyperlink to an exsisting page deletes the line. The link doesn't get inserted (undefined),"**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",task_description,"**Author:** CODE **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",BUG REPRODUCTION 219973,VisualEditor: Adding a hyperlink to an exsisting page deletes the line. The link doesn't get inserted (undefined)," *** This bug has been marked as a duplicate of bug 47413 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 47413 ***",ACTION ON ISSUE 219969,VisualEditor: Adding a hyperlink to an exsisting page deletes the line. The link doesn't get inserted (undefined),"**mh87** wrote: After click on the matching link item it says undefined **Attached**: {F10658}",task_subcomment,"**mh87** wrote: After click on the matching link item it says undefined **Attached**: {F10658}",BUG REPRODUCTION 49419,"VisualEditor: Dirty diffs with FF, but not in Chrome on pages with citations","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",task_description,"Performing small edits on pages with citations like URL results in a clean diff in Chrome, but produces a dirty diff when using Firefox. -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 212180,"VisualEditor: Dirty diffs with FF, but not in Chrome on pages with citations"," *** This bug has been marked as a duplicate of bug 47417 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 47417 ***",ACTION ON ISSUE 212174,"VisualEditor: Dirty diffs with FF, but not in Chrome on pages with citations","Example edit: https://en.wikipedia.org/w/index.php?title=User:Fluffernutter/Kinne&curid=37842561&diff=551148728&oldid=551148307",task_subcomment,"Example edit: URL",SOLUTION USAGE 49258,VisualEditor: Problem with placing cursor inside slug (inline|block) with mouse,"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",task_description,"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",BUG REPRODUCTION 228421,VisualEditor: Problem with placing cursor inside slug (inline|block) with mouse,Fixed here: https://gerrit.wikimedia.org/r/#/c/59199/,task_subcomment,Fixed here: URL,SOLUTION USAGE 48794,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,"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",task_description,"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",BUG REPRODUCTION 225500,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,Now fixed.,task_subcomment,Now fixed.,SOLUTION USAGE 225490,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,Related URL: https://gerrit.wikimedia.org/r/58868 (Gerrit Change I6b2700d65476c4d34ba4a01a88382d7af8e736fb),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I6b2700d65476c4d34ba4a01a88382d7af8e736fb),ACTION ON ISSUE 225481,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,Actually Ed is still working on it.,task_subcomment,Actually Ed is still working on it.,TASK PROGRESS 225476,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,I have added better support for skipping white spaces in 4th patch set: https://gerrit.wikimedia.org/r/#/c/57076/,task_subcomment,I have added better support for skipping white spaces in 4th patch set: URL,SOLUTION DISCUSSION 225473,VisualEditor: Add whitespace skipping to UnicodeJS.wordbreak for word skipping functionality,"Looking at other implementations, sepcifically OpenOffice, they have an ""ignore whitespace"" mode in their nextWord function: https://svn.apache.org/repos/asf/incubator/ooo/symphony/trunk/main/i18npool/source/breakiterator/breakiterator_unicode.cxx which calls an is_whitepsace function, which is defined as: http://www.icu-project.org/apiref/icu4c/uchar_8h.html#a5cef869b23e8d8e649963457cccca68e",task_subcomment,"Looking at other implementations, sepcifically OpenOffice, they have an ""ignore whitespace"" mode in their nextWord function: URL which calls an is_whitepsace function, which is defined as: URL",SOLUTION DISCUSSION 48619,VisualEditor: Allow nodes to handle their own children,"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",task_description,"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",SOLUTION DISCUSSION 214760,VisualEditor: Allow nodes to handle their own children,Done in https://gerrit.wikimedia.org/r/#/c/58645/ and related commits.,task_subcomment,Done in URL and related commits.,SOLUTION USAGE 48520,VisualEditor to edit infobox text fields,"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",task_description,"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."" URL By the time those Wikipedia infoboxes would be filled with Wikidata data, ""easy editing"" should be provided by VisualEditor. -------------------------- **Version**: unspecified **Severity**: enhancement",SOLUTION DISCUSSION 208358,VisualEditor to edit infobox text fields,"Very much on the roadmap already. The Wikidata integration is another issue; will talk with Denny and see about opening distinct bugs for that stuff. *** This bug has been marked as a duplicate of bug 39598 ***",task_subcomment,"Very much on the roadmap already. The Wikidata integration is another issue; will talk with Denny and see about opening distinct bugs for that stuff. *** This bug has been marked as a duplicate of bug 39598 ***",ACTION ON ISSUE 48516,Generalise the Parsoid structure and internal representations.,"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",task_description,"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 URL - 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",SOLUTION DISCUSSION 208160,Generalise the Parsoid structure and internal representations.,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE 208157,Generalise the Parsoid structure and internal representations.,"**molly.white5** wrote: From my brief look at pandoc, it appears that it can do it. As always, it's roundtripping that's the issue.",task_subcomment,"**molly.white5** wrote: From my brief look at pandoc, it appears that it can do it. As always, it's roundtripping that's the issue.",SOLUTION DISCUSSION 208153,Generalise the Parsoid structure and internal representations.,"I agree. If we wind up supporting Markdown, it will be because we've found a way to do HTML <--> Markdown, or at least one direction or t'other. Converting to HTML is simple enough, at least.",task_subcomment,"I agree. If we wind up supporting Markdown, it will be because we've found a way to do HTML <--> Markdown, or at least one direction or t'other. Converting to HTML is simple enough, at least.",SOLUTION DISCUSSION 208148,Generalise the Parsoid structure and internal representations.,"**molly.white5** wrote: I agree that LaTeX to wikitext would not be terribly useful. I wonder if the community would benefit from having some other formats be two-way, though. I'm sure there are people out there who would rather write their articles using Markdown... Then again, if we're trying to make the switch to the VisualEditor anyway, the ability to write articles in Markdown would be of only temporary value.",task_subcomment,"**molly.white5** wrote: I agree that LaTeX to wikitext would not be terribly useful. I wonder if the community would benefit from having some other formats be two-way, though. I'm sure there are people out there who would rather write their articles using Markdown... Then again, if we're trying to make the switch to the VisualEditor anyway, the ability to write articles in Markdown would be of only temporary value.",SOLUTION DISCUSSION 208142,Generalise the Parsoid structure and internal representations.,"I think we could call that ""of dubious usefulness"", but you're the one who's going to have to implement it, so I probably shouldn't dictate anything. In any case I think LaTeX and HTML have a much closer 1:1 ratio than WT and HTML, so it should be much easier to add in, even if it winds up being an afterthought. And as ever, we're in IRC if you'd like any help or guidance :)",task_subcomment,"I think we could call that ""of dubious usefulness"", but you're the one who's going to have to implement it, so I probably shouldn't dictate anything. In any case I think LaTeX and HTML have a much closer 1:1 ratio than WT and HTML, so it should be much easier to add in, even if it winds up being an afterthought. And as ever, we're in IRC if you'd like any help or guidance :)",SOLUTION DISCUSSION 208135,Generalise the Parsoid structure and internal representations.,"**molly.white5** wrote: Alright, that sounds fine as long as you're not concerned with the speed. I'm not familiar with pandoc, but I'll read up on it. I'm curious to see how they perform wikitext <-> LaTeX and HTML <-> LaTeX. Have you discussed whether or not we'll want to be able to roundtrip wikitext and LaTeX?",task_subcomment,"**molly.white5** wrote: Alright, that sounds fine as long as you're not concerned with the speed. I'm not familiar with pandoc, but I'll read up on it. I'm curious to see how they perform wikitext <-> LaTeX and HTML <-> LaTeX. Have you discussed whether or not we'll want to be able to roundtrip wikitext and LaTeX?",SOLUTION DISCUSSION 208128,Generalise the Parsoid structure and internal representations.,"We're chatting on IRC currently, and I think the rough consensus is something like...""HTML should be the common format, and the rest can deal with it."" This makes some amount of sense, though it does mean that, temporarily at least, we'll have to deal with parsing WT to HTML before going to other formats. Since anything beyond that is relatively fast, in terms of performance, we can live with that issue for now. So Molly, we'll throw out the insane charts and maps we've drawn up (which really just consists of one chalk scribble at Harvard) and see what HTML can offer as an intermediary format - to that end, I guess gwicke's suggestion of pandoc is a good place to start.",task_subcomment,"We're chatting on IRC currently, and I think the rough consensus is something like...""HTML should be the common format, and the rest can deal with it."" This makes some amount of sense, though it does mean that, temporarily at least, we'll have to deal with parsing WT to HTML before going to other formats. Since anything beyond that is relatively fast, in terms of performance, we can live with that issue for now. So Molly, we'll throw out the insane charts and maps we've drawn up (which really just consists of one chalk scribble at Harvard) and see what HTML can offer as an intermediary format - to that end, I guess gwicke's suggestion of pandoc is a good place to start.",SOLUTION DISCUSSION 208121,Generalise the Parsoid structure and internal representations.,"Reg. 1. the DOM post processor cannot run before the DOM is built, it requires information that is available only after the DOM is fully built.",task_subcomment,"Reg. 1. the DOM post processor cannot run before the DOM is built, it requires information that is available only after the DOM is fully built.",BUG REPRODUCTION 208110,Generalise the Parsoid structure and internal representations.,"I just ran a quick serialize to see what the timing was like in comparison to a parse - in case we decide to convert HTML into an intermediary format that would translate into whatever other format we want to use. I think the two seconds that it takes to serialize wouldn't be greatly affected by an extra step in the serializer process, and I think the benefits of having a general solution for converting between formats would be greatly useful.",task_subcomment,"I just ran a quick serialize to see what the timing was like in comparison to a parse - in case we decide to convert HTML into an intermediary format that would translate into whatever other format we want to use. I think the two seconds that it takes to serialize wouldn't be greatly affected by an extra step in the serializer process, and I think the benefits of having a general solution for converting between formats would be greatly useful.",SOLUTION DISCUSSION 48506,"Just added single character, but at review all content is replaced","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",task_description,"Steps: 1) Go to URL 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",BUG REPRODUCTION 207494,"Just added single character, but at review all content is replaced"," *** This bug has been marked as a duplicate of bug 43103 ***",task_subcomment," *** This bug has been marked as a duplicate of bug 43103 ***",ACTION ON ISSUE 48505,Clicking outside of link edition popup removes link,"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",task_description,"Steps: 1) Go to URL 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",BUG REPRODUCTION 207443,Clicking outside of link edition popup removes link,"This was fixed in bug 46025 which is bundled in MediaWiki 1.21wmf12 which should be deployed to enwiki tomorrow. Sorry for the delay! *** This bug has been marked as a duplicate of bug 46025 ***",task_subcomment,"This was fixed in bug 46025 which is bundled in MediaWiki 1.21wmf12 which should be deployed to enwiki tomorrow. Sorry for the delay! *** This bug has been marked as a duplicate of bug 46025 ***",ACTION ON ISSUE 48320,VisualEditor: store annotations in a document-wide index/value store and serialize as integer indexes," -------------------------- **Version**: unspecified **Severity**: normal",task_description," -------------------------- **Version**: unspecified **Severity**: normal",BUG REPRODUCTION 220341,VisualEditor: store annotations in a document-wide index/value store and serialize as integer indexes,Related URL: https://gerrit.wikimedia.org/r/54991 (Gerrit Patch-Set: I249a5d48726093d1cb3e36351893f4bff85f52e2/1),task_subcomment,Related URL: GERRIT_URL (Gerrit Patch-Set: I249a5d48726093d1cb3e36351893f4bff85f52e2/1),TASK PROGRESS 220336,VisualEditor: store annotations in a document-wide index/value store and serialize as integer indexes,"Before I go breaking things, I've added tests for AnnotationSet: https://gerrit.wikimedia.org/r/54640",task_subcomment,"Before I go breaking things, I've added tests for AnnotationSet: GERRIT_URL",TASK PROGRESS 48296,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"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/",task_description,"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**: URL",BUG REPRODUCTION 218511,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"Job got deleted, I guess we can forget this bug for now.",task_subcomment,"Job got deleted, I guess we can forget this bug for now.",ISSUE CONTENT MANAGEMENT 218504,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"Yeah, we disabled it because there was no point in keeping it around. There's some hacky workaround, but it seemed really complicated and not worth the work at that time.",task_subcomment,"Yeah, we disabled it because there was no point in keeping it around. There's some hacky workaround, but it seemed really complicated and not worth the work at that time.",SOLUTION DISCUSSION 218497,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"The tests seem to be working now. Has this been fixed or have certain testing paths been disabled? Is there something we can do on our end?",task_subcomment,"The tests seem to be working now. Has this been fixed or have certain testing paths been disabled? Is there something we can do on our end?",TESTING 218491,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"daemon seems to have broken it further, though I'm not sure why. I tried letting the server get set up, and I tried making sure my options were correct, but the parsoid server doesn't seem to like being run with daemon.",task_subcomment,"daemon seems to have broken it further, though I'm not sure why. I tried letting the server get set up, and I tried making sure my options were correct, but the parsoid server doesn't seem to like being run with daemon.",BUG REPRODUCTION 218484,Jenkins: Parsoid server check gets killed because of Jenkins' paranoia (re: file descriptors),"The job dashboard is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/ An example console is https://integration.mediawiki.org/ci/view/All/job/parsoid-server-sanity-check/65/console After the worker have been forked, Jenkins detects some file descriptor leakage and cancel the build: Process leaked file descriptors. See http://wiki.jenkins-ci.org/display/JENKINS/Spawning+processes+from+build for more information They point to http://software.clapper.org/daemonize/ . But maybe we can use /usr/bin/daemon for the same effect.",task_subcomment,"The job dashboard is URL An example console is URL After the worker have been forked, Jenkins detects some file descriptor leakage and cancel the build: Process leaked file descriptors. See URL for more information They point to URL . But maybe we can use /usr/bin/daemon for the same effect.",SOLUTION DISCUSSION 47341,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"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}",task_description,"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}",MOTIVATION 212897,Parsoid: Incorrect rendering for [[Template:Disambiguation]],A reasonable resolution of this issue. :),task_subcomment,A reasonable resolution of this issue. :),SOLUTION DISCUSSION 212890,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"Indeed. The following edit by me fixed it for Parsoid: https://en.wikipedia.org/w/index.php?title=Template%3ADmbox&diff=540384230&oldid=466538335 Seems like a reasonable change to make. Not sure how common this is but I think in most cases editors will understand as in most cases this is already how it is. Leading space after a line break causes a 

    . The reason the line break is there is probably by mistake, and nothing broke so it was forgotten/left.

Lets hope it is not too common.",task_subcomment,"Indeed. The following edit by me fixed it for Parsoid:

URL

Seems like a reasonable change to make. Not sure how common this is but I think in most cases editors will understand as in most cases this is already how it is. Leading space after a line break causes a 
    . The reason the line break is there is probably by mistake, and nothing broke so it was forgotten/left.

Lets hope it is not too common.",ACTION ON ISSUE
212883,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"This can be narrowed down to the difference between these two table cells.  Look at PHP parser output for these two tds in the table:


    

    

  a

 b


    

    

""a"" is not wrapped in a pre-tag, but ""b"" is.  

http://www.mediawiki.org/wiki/User:Ssastry/Tests:Odd_pre_in_td_behavior

Parsoid wraps both in a pre-tag which is the reason why Parsoid output is different from PHP output.  This seems a PHP parser bug to me, not a Parsoid bug.  I imagine we want to be bug-to-bug compatible, but I am not sure what the correct behavior for this is.",task_subcomment,"This can be narrowed down to the difference between these two table cells.  Look at PHP parser output for these two tds in the table:


    

    

  a

 b


    

    

""a"" is not wrapped in a pre-tag, but ""b"" is.  

URL

Parsoid wraps both in a pre-tag which is the reason why Parsoid output is different from PHP output.  This seems a PHP parser bug to me, not a Parsoid bug.  I imagine we want to be bug-to-bug compatible, but I am not sure what the correct behavior for this is.",BUG REPRODUCTION
212875,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"This might be a bug in https://gerrit.wikimedia.org/r/#/c/32405/ or a regression.  The 
     is coming from an #if parser function which should not have as per that commit message.

Will investigate.",task_subcomment,"This might be a bug in URL or a regression.  The 
     is coming from an #if parser function which should not have as per that commit message.

Will investigate.",INVESTIGATION AND EXPLORATION
212867,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"Created attachment 11841
HTML of {{disambiguation}} from Parsoid

The main problem is the presence of a 
     that shouldn't be there.

**Attached**: {F10465}",task_subcomment,"Created attachment 11841
HTML of {{disambiguation}} from Parsoid

The main problem is the presence of a 
     that shouldn't be there.

**Attached**: {F10465}",BUG REPRODUCTION
212862,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"Created attachment 11840
Screenshot of {{disambiguation}} from Parsoid

**Attached**: {F10464}",task_subcomment,"Created attachment 11840
Screenshot of {{disambiguation}} from Parsoid

**Attached**: {F10464}",ACTION ON ISSUE
212856,Parsoid: Incorrect rendering for [[Template:Disambiguation]],"Created attachment 11839
HTML of {{disambiguation}} on [[Loco]] at en.wikipedia.org

**Attached**: {F10463}",task_subcomment,"Created attachment 11839
HTML of {{disambiguation}} on [[Loco]] at en.wikipedia.org

**Attached**: {F10463}",ATTACHMENT
47024,Parsoid: Tables don't round-trip cleanly,"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",task_description,"See URL 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",SOLUTION USAGE
219694,Parsoid: Tables don't round-trip cleanly,"The first normalization is actually the other way around: border=1 is normalized to border=""1"".

This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",task_subcomment,"The first normalization is actually the other way around: border=1 is normalized to border=""1"".

This is the expected degree of normalization for non-selective serialization, so closing as wontfix. Selective serialization is becoming smarter, and will soon only normalize a table cell or even only a part of a table cell's content, which will hide this issue normally.",SOLUTION DISCUSSION
46969,Parsoid crashes when serializing page with colon in title,"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]. (/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]. (/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",task_description,"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]. (/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]. (/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",BUG REPRODUCTION
216497,Parsoid crashes when serializing page with colon in title,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
216490,Parsoid crashes when serializing page with colon in title,"(In reply to comment #0)
> 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
> 
Ignore this one, this is due to a misconfiguration on my end.

> 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.
And this behavior occurs on the command line but not from my browser, for some reason.",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
Ignore this one, this is due to a misconfiguration on my end.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
And this behavior occurs on the command line but not from my browser, for some reason.",MOTIVATION
46927,VisualEditor: VE chokes on unexpected redirect response from Parsoid,"**Author:** `phil`

**Description:**
I created a page using the normal editor that was



File:Example.jpg|Caption1
#REDIRECT [[Target page name]]



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",task_description,"**Author:** CODE

**Description:**
I created a page using the normal editor that was



File:Example.jpg|Caption1
#REDIRECT [[Target page name]]



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",BUG REPRODUCTION
214053,VisualEditor: VE chokes on unexpected redirect response from Parsoid,"Phil,

I've checked and this is now fixed (in part - there's the wider question of Parsoid and redirection which is covered in bug 45808) - am marking as closed. Thank you again for your bug report!

James.",task_subcomment,"Phil,

I've checked and this is now fixed (in part - there's the wider question of Parsoid and redirection which is covered in bug 45808) - am marking as closed. Thank you again for your bug report!

James.",ACTION ON ISSUE
214045,VisualEditor: VE chokes on unexpected redirect response from Parsoid,"**phil** wrote:

Selecting the OK option to Retry brings the error dialog back up so the only option is to Cancel unless you want to spend all day pressing OK

thanks for the extra info on how redirect works - or is meant to work",task_subcomment,"**phil** wrote:

Selecting the OK option to Retry brings the error dialog back up so the only option is to Cancel unless you want to spend all day pressing OK

thanks for the extra info on how redirect works - or is meant to work",SOLUTION USAGE
214038,VisualEditor: VE chokes on unexpected redirect response from Parsoid,"Phil, did this happen when you retried? That error message (which sucks, and we're going to fix as part of bug 44354) just means that it couldn't hail the Parsoid server at the time, and normally means that nothing went wrong other than the server availability.

More generally, when you edit a page which as has a redirect OR a redirect-like string that isn't a redirect because it's not at the top of the page, Parsoid follows the redirect and returns the document that the redirect points to, which is a pair of bugs (we'll need to be able to edit #REDIRECT statements, so it shouldn't return the redirected page, and it should behave the same way as the PHP parser with regard to what is considered a redirect).",task_subcomment,"Phil, did this happen when you retried? That error message (which sucks, and we're going to fix as part of bug 44354) just means that it couldn't hail the Parsoid server at the time, and normally means that nothing went wrong other than the server availability.

More generally, when you edit a page which as has a redirect OR a redirect-like string that isn't a redirect because it's not at the top of the page, Parsoid follows the redirect and returns the document that the redirect points to, which is a pair of bugs (we'll need to be able to edit #REDIRECT statements, so it shouldn't return the redirected page, and it should behave the same way as the PHP parser with regard to what is considered a redirect).",INVESTIGATION AND EXPLORATION
46838,VisualEditor: Multiple toolbars created if tabs switched before initialization is complete,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
208579,VisualEditor: Multiple toolbars created if tabs switched before initialization is complete,Now merged.,task_subcomment,Now merged.,ACTION ON ISSUE
208575,VisualEditor: Multiple toolbars created if tabs switched before initialization is complete,"Whoops, not yet merged.",task_subcomment,"Whoops, not yet merged.",ACTION ON ISSUE
208571,VisualEditor: Multiple toolbars created if tabs switched before initialization is complete,Merged.,task_subcomment,Merged.,SOLUTION DISCUSSION
208567,VisualEditor: Multiple toolbars created if tabs switched before initialization is complete,Patch in: https://gerrit.wikimedia.org/r/48491,task_subcomment,Patch in: GERRIT_URL,TASK PROGRESS
46780,VisualEditor: What Heading levels are offered should flex based,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
231156,VisualEditor: What Heading levels are offered should flex based,"Levels of headings available will need to be tweakable for local integrations - for example, we probably don't want to allow H1s in the article namespace on our content wikis.

However, H6s do in fact work and should be made available in general to HTML editors; not sure whether we should provide them in article space.

Am marking this as a duplicate of bug 43334 which talks about H1s; will adjust that one.

*** This bug has been marked as a duplicate of bug 43334 ***",task_subcomment,"Levels of headings available will need to be tweakable for local integrations - for example, we probably don't want to allow H1s in the article namespace on our content wikis.

However, H6s do in fact work and should be made available in general to HTML editors; not sure whether we should provide them in article space.

Am marking this as a duplicate of bug 43334 which talks about H1s; will adjust that one.

*** This bug has been marked as a duplicate of bug 43334 ***",BUG REPRODUCTION
231149,VisualEditor: What Heading levels are offered should flex based,"Created attachment 11760
Screenshot showing H1 to H6 in VisualEditor mode

**Attached**: {F11017}",task_subcomment,"Created attachment 11760
Screenshot showing H1 to H6 in VisualEditor mode

**Attached**: {F11017}",ACTION ON ISSUE
231140,VisualEditor: What Heading levels are offered should flex based,"Created attachment 11759
Screenshot showing H1 to H6 in read mode

**Attached**: {F11015}",task_subcomment,"Created attachment 11759
Screenshot showing H1 to H6 in read mode

**Attached**: {F11015}",BUG REPRODUCTION
46779,Parsoid: Linktrails should get a  added on serialisation,"**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}",task_description,"**Author:** CODE

**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}",BUG REPRODUCTION
231072,Parsoid: Linktrails should get a  added on serialisation,"Ah, couldn't find the bug; thanks, Gabriel.

*** This bug has been marked as a duplicate of bug 33091 ***",task_subcomment,"Ah, couldn't find the bug; thanks, Gabriel.

*** This bug has been marked as a duplicate of bug 33091 ***",ACTION ON ISSUE
231068,Parsoid: Linktrails should get a  added on serialisation,"To me it seems that the VE should produce a DOM including the space: 

bar baz

If that is not the case, then this is a bug in VE. Escaping for legitimate link trails was fixed in bug 33091, which is not yet deployed.

So either way, I don't think there is a bug in Parsoid here.",task_subcomment,"To me it seems that the VE should produce a DOM including the space: 

bar baz

If that is not the case, then this is a bug in VE. Escaping for legitimate link trails was fixed in bug 33091, which is not yet deployed.

So either way, I don't think there is a bug in Parsoid here.",MOTIVATION
231063,Parsoid: Linktrails should get a  added on serialisation,"This appears to be a problem in Parsoid.

In VisualEditor the user has (effectively) created barbaz; it is unexpectedly converted into [[foo|bar]]baz instead of [[foo|bar]]baz, hence the confusion.

Gabriel, thoughts?",task_subcomment,"This appears to be a problem in Parsoid.

In VisualEditor the user has (effectively) created barbaz; it is unexpectedly converted into [[foo|bar]]baz instead of [[foo|bar]]baz, hence the confusion.

Gabriel, thoughts?",ACTION ON ISSUE
46686,VisualEditor: Opening link inspector without selection in stand alone instance throws error.,"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",task_description,"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",BUG REPRODUCTION
225462,VisualEditor: Opening link inspector without selection in stand alone instance throws error.,Now merged.,task_subcomment,Now merged.,ACTION ON ISSUE
225460,VisualEditor: Opening link inspector without selection in stand alone instance throws error.,Patched in https://gerrit.wikimedia.org/r/#/c/47615/,task_subcomment,Patched in URL,SOLUTION USAGE
46478,VisualEditor: Unexpected behavior when line starts with space,"nowiki tags

edit a line in VE such that it starts with a space

VE unexpectedly inserts  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  tags up to the formatted character and leaves the rest of the line alone

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F10444}",task_description,"nowiki tags

edit a line in VE such that it starts with a space

VE unexpectedly inserts  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  tags up to the formatted character and leaves the rest of the line alone

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F10444}",BUG REPRODUCTION
212656,VisualEditor: Unexpected behavior when line starts with space,"... but when you save "" le'''''adi'''''ing space"" in the wikitext editor, you get 
    le'''''adi'''''ing space
    , not 
     le'''''adi'''''ing space
    . The  tags are necessary to get the latter, which is what the VE user actually typed.

Closing as WONTFIX.",task_subcomment,"... but when you save "" le'''''adi'''''ing space"" in the wikitext editor, you get 
    le'''''adi'''''ing space
    , not 
     le'''''adi'''''ing space
    . The  tags are necessary to get the latter, which is what the VE user actually typed.

Closing as WONTFIX.",ACTION ON ISSUE
212649,VisualEditor: Unexpected behavior when line starts with space,"Created attachment 11719
normal editor vs. VE on save

**Attached**: {F10447}",task_subcomment,"Created attachment 11719
normal editor vs. VE on save

**Attached**: {F10447}",BUG REPRODUCTION
212641,VisualEditor: Unexpected behavior when line starts with space,"Created attachment 11718
normal editor vs. VE preview

**Attached**: {F10446}",task_subcomment,"Created attachment 11718
normal editor vs. VE preview

**Attached**: {F10446}",SOLUTION USAGE
212634,VisualEditor: Unexpected behavior when line starts with space,"
Maybe I'm missing something. 

I've attached a screen shot comparing preview in the normal editor to preview in VE where both are doing exactly the same operation:  editing the string "" leading space"" where the ""adi"" part of the string is made both bold and italic. 

The normal editor does not add  tags to this string.  VE adds  tags. 

The normal editor does not save the text with  tags.  VE saves the text with  tags. 

It may be that VE adds  tags by design, but they seem unnecessary.  Again, I could be wrong.",task_subcomment,"
Maybe I'm missing something. 

I've attached a screen shot comparing preview in the normal editor to preview in VE where both are doing exactly the same operation:  editing the string "" leading space"" where the ""adi"" part of the string is made both bold and italic. 

The normal editor does not add  tags to this string.  VE adds  tags. 

The normal editor does not save the text with  tags.  VE saves the text with  tags. 

It may be that VE adds  tags by design, but they seem unnecessary.  Again, I could be wrong.",BUG REPRODUCTION
212630,VisualEditor: Unexpected behavior when line starts with space,"No, this is expected behaviour. A line that starts with "" "" in wikitext is a pre-formatted block. If VE just let users save 
     Foo
     as "" Foo"" they'd get very unexpected results.

We don't (and won't) expect users to understand that certain characters are magic and can't be used in certain places, and instead we need to escape character sequences they've entered that happen to be 'magic'.

Unless I'm missing something?",task_subcomment,"No, this is expected behaviour. A line that starts with "" "" in wikitext is a pre-formatted block. If VE just let users save 
     Foo
     as "" Foo"" they'd get very unexpected results.

We don't (and won't) expect users to understand that certain characters are magic and can't be used in certain places, and instead we need to escape character sequences they've entered that happen to be 'magic'.

Unless I'm missing something?",EXPECTED BEHAVIOR
212627,VisualEditor: Unexpected behavior when line starts with space,look what happens in the regular editor.  I think VE is doing something really strange here.,task_subcomment,look what happens in the regular editor.  I think VE is doing something really strange here.,BUG REPRODUCTION
212625,VisualEditor: Unexpected behavior when line starts with space,I'm not entirely convinced what the expected behaviour is - should it be just the leading ' ' character that is wrapped in  elements?,task_subcomment,I'm not entirely convinced what the expected behaviour is - should it be just the leading ' ' character that is wrapped in  elements?,EXPECTED BEHAVIOR
212622,VisualEditor: Unexpected behavior when line starts with space,"Created attachment 11706
nowiki tags with formatted text

**Attached**: {F10445}",task_subcomment,"Created attachment 11706
nowiki tags with formatted text

**Attached**: {F10445}",ACTION ON ISSUE
46313,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"**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",task_description,"**Author:** CODE

**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 = 'URL

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**: URL",BUG REPRODUCTION
226815,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"

*** This bug has been marked as a duplicate of bug 44483 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 44483 ***",ACTION ON ISSUE
226812,Parsoid should support passing on an authenticated user's read right (when MW API supports that),"**mail** wrote:

http://lists.wikimedia.org/pipermail/wikitext-l/2013-January/000750.html

Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE.
I hope there will be the possibility to have it FALSE in the future :)",task_subcomment,"**mail** wrote:

URL

Solved by setting $wgGroupPermissions['*']['read'] from FALSE to TRUE.
I hope there will be the possibility to have it FALSE in the future :)",SOLUTION USAGE
45925,SMW: Refresh tab (purge) is always collapsed when using the Vector skin,"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",task_description,"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",SOLUTION USAGE
420024,SMW: Refresh tab (purge) is always collapsed when using the Vector skin,"The Semantic MediaWiki developers requested in https://phabricator.wikimedia.org/T64114 to move their task tracking to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues and to close remaining tasks in Wikimedia Phabricator.  If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues .  We are sorry for the inconvenience.",task_subcomment,"The Semantic MediaWiki developers requested in URL to move their task tracking to URL and to close remaining tasks in Wikimedia Phabricator.  If you still face the problem reported in this task in a supported version of SMW, please feel free to transfer your report to URL .  We are sorry for the inconvenience.",ISSUE CONTENT MANAGEMENT
229648,SMW: Refresh tab (purge) is always collapsed when using the Vector skin,"Removing relation to Vector skin issues. This is the default behaviour indeed, but individual menu items can indicate whether or not Vector should allow them to ""come out  of the menu"" and onto the horizontal menu bar when space is available.

The navigation links array in PHP (exposed via the SkinTemplateNavigation hook[1]) contains an array for each tab. Setting property 'primary' to boolean true will instruct Vector to apply class ""collapsible"".

Example:
 https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/1f136f9d1d/VisualEditor.hooks.php#L96-L101


[1] https://www.mediawiki.org/wiki/Manual:Hooks/SkinTemplateNavigation",task_subcomment,"Removing relation to Vector skin issues. This is the default behaviour indeed, but individual menu items can indicate whether or not Vector should allow them to ""come out  of the menu"" and onto the horizontal menu bar when space is available.

The navigation links array in PHP (exposed via the SkinTemplateNavigation hook[1]) contains an array for each tab. Setting property 'primary' to boolean true will instruct Vector to apply class ""collapsible"".

Example:
 URL


[1] URL",SOLUTION USAGE
45841,"VisualEditor: Make link inspector aware of annotations, rather than just target strings","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",task_description,"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**:
URL",BUG REPRODUCTION
224674,"VisualEditor: Make link inspector aware of annotations, rather than just target strings",Made it to master for the 2013-01-16 branch.,task_subcomment,Made it to master for the 2013-01-16 branch.,SOLUTION USAGE
224670,"VisualEditor: Make link inspector aware of annotations, rather than just target strings",Addressed in gerrit 43028.,task_subcomment,Addressed in gerrit 43028.,SOLUTION USAGE
45566,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","**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",task_description,"**Author:** CODE

**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 URL the bug should have be fixed. 
P.S. I'm using latest VE and Parsoid.

--------------------------
**Version**: unspecified
**Severity**: critical
**OS**: Linux",BUG REPRODUCTION
208325,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","**Coiby.Xu** wrote:

I'm sorry, this should be a bug. It occurs due to the wrong setting in js/api/localsettings.js
env.setInterwiki( 'localhost', 'http://' );",task_subcomment,"**Coiby.Xu** wrote:

I'm sorry, this should be a bug. It occurs due to the wrong setting in js/api/localsettings.js
env.setInterwiki( 'localhost', 'URL );",BUG REPRODUCTION
208320,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","**blue.snow013** wrote:

(In reply to comment #4)
> (In reply to comment #3)
> > I have the same problems on the latest VE and Parsoid,too.
> > could someone help me?
> Could you tell us:
> * What $wgVisualEditorParsoidURL and $wgVisualEditorParsoidPrefix are set to
> in
> your LocalSettings.php
> * the contents of Parsoid's localsettings.js file
> * where Parsoid is running

Here is my LocalSettings.php

require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");
 
// Allow using VisualEditor in the main namespace only (default)
$wgVisualEditorNamespaces = array( NS_MAIN );
 
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
 
// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';

$wgVisualEditorParsoidURL = 'http://localhost:8000/';


And my localsettings.js:

exports.setup = function( config, env ) {
        // The URL here is supposed to be your MediaWiki installation root
        env.setInterwiki( 'localhost', 'http://localhost/wiki' );

        // Use the PHP preprocessor to expand templates via the MW API
        env.usePHPPreProcessor = false;
};

// Use selective serialization
exports.useSelser = false;
                      
I run the Parsoid in the background using node on my own server.

Thanks!",task_subcomment,"**blue.snow013** wrote:

(In reply to comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Here is my LocalSettings.php

require_once(""$IP/extensions/VisualEditor/VisualEditor.php"");
 
// Allow using VisualEditor in the main namespace only (default)
$wgVisualEditorNamespaces = array( NS_MAIN );
 
// Enable by default for everybody
$wgDefaultUserOptions['visualeditor-enable'] = 1;
 
// Don't allow users to disable it
$wgHiddenPrefs[] = 'visualeditor-enable';

$wgVisualEditorParsoidURL = 'URL


And my localsettings.js:

exports.setup = function( config, env ) {
        // The URL here is supposed to be your MediaWiki installation root
        env.setInterwiki( 'localhost', 'URL );

        // Use the PHP preprocessor to expand templates via the MW API
        env.usePHPPreProcessor = false;
};

// Use selective serialization
exports.useSelser = false;
                      
I run the Parsoid in the background using node on my own server.

Thanks!",SOLUTION USAGE
208311,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","(In reply to comment #3)
> I have the same problems on the latest VE and Parsoid,too.
> could someone help me?
Could you tell us:
* What $wgVisualEditorParsoidURL and $wgVisualEditorParsoidPrefix are set to in your LocalSettings.php
* the contents of Parsoid's localsettings.js file
* where Parsoid is running",task_subcomment,"(In reply to comment #3)
QUOTE
QUOTE
Could you tell us:
* What $wgVisualEditorParsoidURL and $wgVisualEditorParsoidPrefix are set to in your LocalSettings.php
* the contents of Parsoid's localsettings.js file
* where Parsoid is running",SOLUTION DISCUSSION
208304,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","**blue.snow013** wrote:

I have the same problems on the latest VE and Parsoid,too.
could someone help me?",task_subcomment,"**blue.snow013** wrote:

I have the same problems on the latest VE and Parsoid,too.
could someone help me?",BUG REPRODUCTION
208297,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","**Coiby.Xu** wrote:

I'm running it on my own server.
Here's the address for testing: wiki.aiesec.cn/index.php?title=Test.
If you click ""VisualEditor"", the above error will occur.
> (In reply to comment #0)
> > P.S. I'm using latest VE and Parsoid.
> 
> Are you saying you're running it on your own server? Or are you using
> Wikipedia?",task_subcomment,"**Coiby.Xu** wrote:

I'm running it on my own server.
Here's the address for testing: wiki.aiesec.cn/index.php?title=Test.
If you click ""VisualEditor"", the above error will occur.
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE",BUG REPRODUCTION
208293,"VisualEditor: Fix ""Error loading data from server: error. Would you like to retry?""","(In reply to comment #0)
> P.S. I'm using latest VE and Parsoid.

Are you saying you're running it on your own server? Or are you using Wikipedia?",task_subcomment,"(In reply to comment #0)
QUOTE

Are you saying you're running it on your own server? Or are you using Wikipedia?",SOLUTION DISCUSSION
45460,VisualEditor: Empty editnotices appear as notices,"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",task_description,"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",BUG REPRODUCTION
202768,VisualEditor: Empty editnotices appear as notices,"This is due to English Wikipedia's self-invented system for edit notices where their [[MediaWiki:Editnotice-0]] / [[Template:Editnotice load]] displays an html structure even when there is no edit notice created (namely the link to ""create"" the edit notice, hidden/shown with usergroup css).

Although that system is rather unhandy (as it means there will always be an edit notice even when this is not intended), it is possible to work around it by parsing the edit notice client side in javascript and applying the local stylesheet and check whether there are any non-hidden nodes.

This was done and fixed in master. It will be deployed in the next branch.

*** This bug has been marked as a duplicate of bug 43013 ***",task_subcomment,"This is due to English Wikipedia's self-invented system for edit notices where their [[MediaWiki:Editnotice-0]] / [[Template:Editnotice load]] displays an html structure even when there is no edit notice created (namely the link to ""create"" the edit notice, hidden/shown with usergroup css).

Although that system is rather unhandy (as it means there will always be an edit notice even when this is not intended), it is possible to work around it by parsing the edit notice client side in javascript and applying the local stylesheet and check whether there are any non-hidden nodes.

This was done and fixed in master. It will be deployed in the next branch.

*** This bug has been marked as a duplicate of bug 43013 ***",SOLUTION DISCUSSION
45429,Removing link trail doesn't affect the output,"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",task_description,"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",SOLUTION DISCUSSION
200760,Removing link trail doesn't affect the output,Finally squashed in https://gerrit.wikimedia.org/r/#/c/43985/.,task_subcomment,Finally squashed in URL,SOLUTION USAGE
200752,Removing link trail doesn't affect the output,Change I126116de should fix this.,task_subcomment,Change I126116de should fix this.,SOLUTION DISCUSSION
200743,Removing link trail doesn't affect the output,"You can replicate this in VisualEditor in fact by removing the trailing 's' when the linked 's' came via a link-trail in the original wikitext.    

We record information about original wikitext in html-attributes.  Recording source information in attributes and using it is not a hack -- it is necessary to preserve original wikitext when it is unmodified (which is going to be more often than not).  We now need to fix our serialization to detect modifications in cases like this where we are currently not.",task_subcomment,"You can replicate this in VisualEditor in fact by removing the trailing 's' when the linked 's' came via a link-trail in the original wikitext.    

We record information about original wikitext in html-attributes.  Recording source information in attributes and using it is not a hack -- it is necessary to preserve original wikitext when it is unmodified (which is going to be more often than not).  We now need to fix our serialization to detect modifications in cases like this where we are currently not.",SOLUTION DISCUSSION
45323,PHP Fatal error:  Call to undefined method Title::getEditNotices() in extensions/VisualEditor/ApiVisualEditor.php,"**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",task_description,"**Author:** CODE

**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",INVESTIGATION AND EXPLORATION
194880,PHP Fatal error:  Call to undefined method Title::getEditNotices() in extensions/VisualEditor/ApiVisualEditor.php,This method was added into MediaWiki core in Gerrit change 36240. You'll need to update to that.,task_subcomment,This method was added into MediaWiki core in Gerrit change 36240. You'll need to update to that.,SOLUTION USAGE
45258,VisualEditor: Tooltip broken on outdent button,"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",task_description,"URL

Change
visualeditor-outdentationbutton-outdent-tooltip
to
visualeditor-indentationbutton-outdent-tooltip

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
190926,VisualEditor: Tooltip broken on outdent button,Thanks for the report.  This was patched in. https://gerrit.wikimedia.org/r/#/c/38810/,task_subcomment,Thanks for the report.  This was patched in. URL,ACTION ON ISSUE
45119,Reporter missing in IRC announcement of new issue,"The reporter is missing in the IRC announcements of new issues in #mediawiki.

Observed IRC output:

(NEW) VisualEditor: Support  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  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",task_description,"The reporter is missing in the IRC announcements of new issues in #mediawiki.

Observed IRC output:

(NEW) VisualEditor: Support  extension - URL normal; VisualEditor: General; ()
(NEW) File will not change from original version - URL normal; MediaWiki: File management; ()
(NEW) prevent update.php from updating database schemata of wgSharedTables - URL enhancement; MediaWiki: Installer; ()

Expected IRC output: ""()"" replaced by ""(UserName)"":

(NEW) VisualEditor: Support  extension - URL normal; VisualEditor: General; (Raimond Spekking)
(NEW) File will not change from original version - URL normal; MediaWiki: File management; (Adam Cuerden)
(NEW) prevent update.php from updating database schemata of wgSharedTables - URL enhancement; MediaWiki: Installer; (Gregor Hagedorn)

--------------------------
**Version**: wmf-deployment
**Severity**: normal",BUG REPRODUCTION
183160,Reporter missing in IRC announcement of new issue,"

*** This bug has been marked as a duplicate of bug 42774 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 42774 ***",ACTION ON ISSUE
45078,VisualEditor never loads,"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",task_description,"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",BUG REPRODUCTION
205134,VisualEditor never loads,Wth?! Why does it take so much time to load. But then it atlast worked.,task_subcomment,Wth?! Why does it take so much time to load. But then it atlast worked.,TASK PROGRESS
45064,VisualEditor: Skip the inspector menu on links,"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",task_description,"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",SOLUTION DISCUSSION
204232,VisualEditor: Skip the inspector menu on links,"What you explain is pretty depressing. Just the necessity to learn all the icons for all the rare-to-be-used ""inspectors"" that will accumulate over time sounds like it may continue to prevent a majority of people from editing ... I fear it is dangerous if programmers try to design the user interface for normal people.

The method used by Google docs works really well for me: when clicking on an existing link, it directly shows the link target and offers ""change"" and ""remove"". Nice, simple, accessible, intuitive. And all the other non-context sensitive options for normal text stay in the menu and button and can be accessed from there. No toolbar full of accessor/inspector items that moves with the cursor and prevents reading.",task_subcomment,"What you explain is pretty depressing. Just the necessity to learn all the icons for all the rare-to-be-used ""inspectors"" that will accumulate over time sounds like it may continue to prevent a majority of people from editing ... I fear it is dangerous if programmers try to design the user interface for normal people.

The method used by Google docs works really well for me: when clicking on an existing link, it directly shows the link target and offers ""change"" and ""remove"". Nice, simple, accessible, intuitive. And all the other non-context sensitive options for normal text stay in the menu and button and can be accessed from there. No toolbar full of accessor/inspector items that moves with the cursor and prevents reading.",SOLUTION DISCUSSION
204226,VisualEditor: Skip the inspector menu on links,"(In reply to comment #2)
> I remain unconvinced. What other ""inspectors"" do you want to call on a link?

It's not ""on a link"", it's ""on some text"" - yes, this includes links if one is set, but there will be quite a few annotation inspectors; in complex cases, we may need to come up with a new interface if it ever got about half a dozen or so. What you're seeing is an artefact that we haven't written the other annotation inspectors yet - not that they aren't applicable. For example, we'll be creating (or helping others create) annotation inspectors for setting the selection's language (as used on the English Wikipedia through a template, but invaluable to our multi-lingual wikis), modifying text colour and other funky formatting, marking up the content as an address (as used through an extension in Wikivoyage) or as a status update (used on MediaWiki.org), and no-doubt several others that we haven't even thought of yet.

Note that this menu (which is purely about annotation inspectors) doesn't trigger on text that isn't already a link, as we don't show it when there are no appropriate annotation inspectors for the context.

There will also be a bunch of object inspectors for ""complex"" things like references, templates, images and other media, galleries, Wikidata transclusions and queries, music annotations, maths equations, EasyTimeline uses, code blocks with syntax highlighting, poems, and dozens of other things that are block-level parser hooks of some kind, as tailored to the wiki and within that to the context. And, of course, this list will expand over time as the number of things that can be created and edited through the VisualEditor approaches completeness for Wikimedia's cluster install, and for third parties using MediaWiki in their own situations.

Finally, there will be a page-level inspector for page-level meta-data - like categories and language links, the ""magic words"" that perform title over-rides, redirects, suppression of the table of contents, etc.

[Snip]

> I fear it will be an even worse user experience if users have to choose
> between various ""inspectors"" for a link. And I fear the choices will be
> hard to make until they have read a couple of help pages. This is not what
> I hope the VE will achieve...

Certainly, part of our job is to make a complex task as simple as possible - but, to steal the phrase, no simpler. I fear that we haven't explained the concept of annotation inspectors in the design language well enough for the above to be clear, for which I apologise.

> I would prefer a bit of object-oriented context smartness. Perhaps, to
> satisfy the generic design (I can imagine some alternative choices for some
> other objects...): why not skip the ""choose an inspector"" step if there is
> only one choice for a given object in a given context? This would easily
> support cases where an object may truly need a choice of inspectors, but
> avoid the clumsiness of the current approach.

This would mean that, as you move the cursor through the text, every time you hit a link, the link inspector would load, filling the screen (and triggering a wasteful and unwanted API request to get the suggested list of pages for the link text). Clearly for you, this would be appropriate, but I don't agree that it's an interface paradigm that would work for most users.

> (Note that the tooltip enhancement does not help on modern touch devices, so
> making the interaction with links to check link correctness painless remains
> an issue.)

Sorry, but this is not true. In an iPad or Android tablet or mobile 'phone, press and hold on a link to be informed of the link's title attribute; voilà, the link destination is revealed. Yes, this is messy, but our job is to be as seemless as possible in integrating with users' operating systems' existing workflows, not inventing our own.",task_subcomment,"(In reply to comment #2)
QUOTE

It's not ""on a link"", it's ""on some text"" - yes, this includes links if one is set, but there will be quite a few annotation inspectors; in complex cases, we may need to come up with a new interface if it ever got about half a dozen or so. What you're seeing is an artefact that we haven't written the other annotation inspectors yet - not that they aren't applicable. For example, we'll be creating (or helping others create) annotation inspectors for setting the selection's language (as used on the English Wikipedia through a template, but invaluable to our multi-lingual wikis), modifying text colour and other funky formatting, marking up the content as an address (as used through an extension in Wikivoyage) or as a status update (used on MediaWiki.org), and no-doubt several others that we haven't even thought of yet.

Note that this menu (which is purely about annotation inspectors) doesn't trigger on text that isn't already a link, as we don't show it when there are no appropriate annotation inspectors for the context.

There will also be a bunch of object inspectors for ""complex"" things like references, templates, images and other media, galleries, Wikidata transclusions and queries, music annotations, maths equations, EasyTimeline uses, code blocks with syntax highlighting, poems, and dozens of other things that are block-level parser hooks of some kind, as tailored to the wiki and within that to the context. And, of course, this list will expand over time as the number of things that can be created and edited through the VisualEditor approaches completeness for Wikimedia's cluster install, and for third parties using MediaWiki in their own situations.

Finally, there will be a page-level inspector for page-level meta-data - like categories and language links, the ""magic words"" that perform title over-rides, redirects, suppression of the table of contents, etc.

[Snip]

QUOTE
QUOTE
QUOTE
QUOTE

Certainly, part of our job is to make a complex task as simple as possible - but, to steal the phrase, no simpler. I fear that we haven't explained the concept of annotation inspectors in the design language well enough for the above to be clear, for which I apologise.

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This would mean that, as you move the cursor through the text, every time you hit a link, the link inspector would load, filling the screen (and triggering a wasteful and unwanted API request to get the suggested list of pages for the link text). Clearly for you, this would be appropriate, but I don't agree that it's an interface paradigm that would work for most users.

QUOTE
QUOTE
QUOTE

Sorry, but this is not true. In an iPad or Android tablet or mobile 'phone, press and hold on a link to be informed of the link's title attribute; voilà, the link destination is revealed. Yes, this is messy, but our job is to be as seemless as possible in integrating with users' operating systems' existing workflows, not inventing our own.",SOLUTION DISCUSSION
204220,VisualEditor: Skip the inspector menu on links,"I remain unconvinced. What other ""inspectors"" do you want to call on a link? (An ""Open link in new tab"" inspector? If yes I propose to integrate such special case functions in the link inspector itself to keep things simple and avoid decisions steps up front). 

I fear it will be an even worse user experience if users have to choose between various ""inspectors"" for a link. And I fear the choices will be hard to make until they have read a couple of help pages. This is not what I hope the VE will achieve...

I would prefer a bit of object-oriented context smartness. Perhaps, to satisfy the generic design (I can imagine some alternative choices for some other objects...): why not skip the ""choose an inspector"" step if there is only one choice for a given object in a given context? This would easily support cases where an object may truly need a choice of inspectors, but avoid the clumsiness of the current approach.

(Note that the tooltip enhancement does not help on modern touch devices, so making the interaction with links to check link correctness painless remains an issue.)",task_subcomment,"I remain unconvinced. What other ""inspectors"" do you want to call on a link? (An ""Open link in new tab"" inspector? If yes I propose to integrate such special case functions in the link inspector itself to keep things simple and avoid decisions steps up front). 

I fear it will be an even worse user experience if users have to choose between various ""inspectors"" for a link. And I fear the choices will be hard to make until they have read a couple of help pages. This is not what I hope the VE will achieve...

I would prefer a bit of object-oriented context smartness. Perhaps, to satisfy the generic design (I can imagine some alternative choices for some other objects...): why not skip the ""choose an inspector"" step if there is only one choice for a given object in a given context? This would easily support cases where an object may truly need a choice of inspectors, but avoid the clumsiness of the current approach.

(Note that the tooltip enhancement does not help on modern touch devices, so making the interaction with links to check link correctness painless remains an issue.)",SOLUTION DISCUSSION
204212,VisualEditor: Skip the inspector menu on links,"This mis-understands the menu - the ""chain icon"" launches the link inspector, but there are potentially quite a few icons in the user's context at this point. We only have the link inspector created at this stage, but we will have more before the VisualEditor is ""finished"".

For the first enhancement, this was fixed in bug 37904 but that has regressed - have re-opened that one.",task_subcomment,"This mis-understands the menu - the ""chain icon"" launches the link inspector, but there are potentially quite a few icons in the user's context at this point. We only have the link inspector created at this stage, but we will have more before the VisualEditor is ""finished"".

For the first enhancement, this was fixed in bug 37904 but that has regressed - have re-opened that one.",BUG REPRODUCTION
45056,VisualEditor: Things are sometimes alienated as block when they should be inline,"""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",task_description,"""phantoms"" text is wrapped into a ""div class=""ve-ce-phantoms"" "" which adds a linebreak because div is a  block element, see URL

Better to use a span I think.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
203706,VisualEditor: Things are sometimes alienated as block when they should be inline,Merged; code will be deployed as part of the 2013-01-16 release cycle.,task_subcomment,Merged; code will be deployed as part of the 2013-01-16 release cycle.,SOLUTION USAGE
203700,VisualEditor: Things are sometimes alienated as block when they should be inline,https://gerrit.wikimedia.org/r/39846,task_subcomment,GERRIT_URL,ACTION ON ISSUE
203693,VisualEditor: Things are sometimes alienated as block when they should be inline,"Fixing summary. Editable nodes are called ""aliens"". The ""phantom"" is the green hatched-out overlay that appears when mousing over an alien. It's an absolutely positioned 
     that exists outside of the main editor DOM. Because of the mouseover effect, you can't actually inspect the aliens themselves easily, but when you do, you'll find that the actual uneditable content is in 
     or  as appropriate.

The issue here is that some things (nowikis in Raymond's example, and I've seen some references do it in the wild) are alienated as alienBlock nodes by ve.dm.Converter when they should really be alienInline nodes.",task_subcomment,"Fixing summary. Editable nodes are called ""aliens"". The ""phantom"" is the green hatched-out overlay that appears when mousing over an alien. It's an absolutely positioned 
     that exists outside of the main editor DOM. Because of the mouseover effect, you can't actually inspect the aliens themselves easily, but when you do, you'll find that the actual uneditable content is in 
     or  as appropriate.

The issue here is that some things (nowikis in Raymond's example, and I've seen some references do it in the wild) are alienated as alienBlock nodes by ve.dm.Converter when they should really be alienInline nodes.",INVESTIGATION AND EXPLORATION
45055,VisualEditor: Escape from LinkAnnotation editor closes annotation editor but leaves suggestion box floating,"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}",task_description,"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}",BUG REPRODUCTION
203667,VisualEditor: Escape from LinkAnnotation editor closes annotation editor but leaves suggestion box floating,"

%%%*** This bug has been marked as a duplicate of bug 43051 ***%%%",task_subcomment,"

%%%*** This bug has been marked as a duplicate of bug 43051 ***%%%",ACTION ON ISSUE
45051,VisualEditor: Suggestion tool fails to close when escaping out of context menu.,"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",task_description,"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",BUG REPRODUCTION
203460,VisualEditor: Suggestion tool fails to close when escaping out of context menu.,Add to deployment milestone.,task_subcomment,Add to deployment milestone.,ACTION ON ISSUE
203454,VisualEditor: Suggestion tool fails to close when escaping out of context menu.,%%%*** Bug 43055 has been marked as a duplicate of this bug. ***%%%,task_subcomment,%%%*** Bug 43055 has been marked as a duplicate of this bug. ***%%%,ACTION ON ISSUE
203450,VisualEditor: Suggestion tool fails to close when escaping out of context menu.,"Escape was normally handled by calling onInput, until yesterday I simplified the close logic.  This slipped through the cracks pre-release.

Patched in https://gerrit.wikimedia.org/r/38468",task_subcomment,"Escape was normally handled by calling onInput, until yesterday I simplified the close logic.  This slipped through the cracks pre-release.

Patched in GERRIT_URL",BUG REPRODUCTION
45036,"VisualEditor: For initial deployment, do not over-ride edit-section links","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",task_description,"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",BUG REPRODUCTION
202693,"VisualEditor: For initial deployment, do not over-ride edit-section links",This appears to have missed the deploy-train; moving.,task_subcomment,This appears to have missed the deploy-train; moving.,ACTION ON ISSUE
202689,"VisualEditor: For initial deployment, do not over-ride edit-section links",Now merged into master.,task_subcomment,Now merged into master.,TASK PROGRESS
202684,"VisualEditor: For initial deployment, do not over-ride edit-section links",Fixed by https://gerrit.wikimedia.org/r/#/c/38451/,task_subcomment,Fixed by URL,SOLUTION USAGE
45033,VisualEditor: Undo just after load of the editor causes JS error.,"Open the editor, Hit Control/Command U.
Throws Exception:
Uncaught TypeError: Cannot read property 'start' of null

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"Open the editor, Hit Control/Command U.
Throws Exception:
Uncaught TypeError: Cannot read property 'start' of null

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
202552,VisualEditor: Undo just after load of the editor causes JS error.,"Also happens for redo.
Patched in: https://gerrit.wikimedia.org/r/#/c/38349/",task_subcomment,"Also happens for redo.
Patched in: URL",BUG REPRODUCTION
44983,VisualEditor:  message is missing,"Seen on the VE-editing interface of https://www.mediawiki.org/wiki/VisualEditor:Test

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"Seen on the VE-editing interface of URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
199407,VisualEditor:  message is missing,Add to deployment milestone.,task_subcomment,Add to deployment milestone.,ACTION ON ISSUE
199404,VisualEditor:  message is missing,Working for me now after a hard refresh.,task_subcomment,Working for me now after a hard refresh.,SOLUTION USAGE
199402,VisualEditor:  message is missing,"The messages are certainly in the i18n file, it probably just needs a l10n cache rebuild. Doing that now.",task_subcomment,"The messages are certainly in the i18n file, it probably just needs a l10n cache rebuild. Doing that now.",SOLUTION DISCUSSION
199398,VisualEditor:  message is missing,"visualeditor-savedialog-title-review is in the i18n file the others aren't..

visualeditor-toolbar-savedialog is also showing as missing...



Certainly, for starters, having all the messages actually defined, and also ""exported"" to JS where necessary would be useful",task_subcomment,"visualeditor-savedialog-title-review is in the i18n file the others aren't..

visualeditor-toolbar-savedialog is also showing as missing...



Certainly, for starters, having all the messages actually defined, and also ""exported"" to JS where necessary would be useful",SOLUTION DISCUSSION
199391,VisualEditor:  message is missing,"Confirming that this is a bug on mediawiki.org. I was about to file a bug and include a screenshot, but I think this should be pretty easy to spot in the interface on mediawiki.org.

This may not be a VisualEditor bug, per se. It could be an issue with localisation cache.",task_subcomment,"Confirming that this is a bug on mediawiki.org. I was about to file a bug and include a screenshot, but I think this should be pretty easy to spot in the interface on mediawiki.org.

This may not be a VisualEditor bug, per se. It could be an issue with localisation cache.",BUG REPRODUCTION
199387,VisualEditor:  message is missing,"Also messages in that dialog, like , ,  etc",task_subcomment,"Also messages in that dialog, like , ,  etc",SOLUTION DISCUSSION
44935,"VisualEditor: While using link inspector, transaction hangs and page eventually explodes.","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",task_description,"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",BUG REPRODUCTION
196646,"VisualEditor: While using link inspector, transaction hangs and page eventually explodes.",Fixed in https://gerrit.wikimedia.org/r/#/c/38004/,task_subcomment,Fixed in URL,SOLUTION USAGE
44925,VisualEditor: Inspector doesn't open properly,"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",task_description,"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",BUG REPRODUCTION
196092,VisualEditor: Inspector doesn't open properly,*** Bug 37856 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 37856 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
196086,VisualEditor: Inspector doesn't open properly,Fixed in gerrit 37945.,task_subcomment,Fixed in gerrit 37945.,SOLUTION USAGE
44920,VisualEditor: Re-enable the feedback tool for deployment,"Point to [[Project:VisualEditor/Feedback]] for now.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"Point to [[Project:VisualEditor/Feedback]] for now.

--------------------------
**Version**: unspecified
**Severity**: normal",ACTION ON ISSUE
195743,VisualEditor: Re-enable the feedback tool for deployment,See also https://gerrit.wikimedia.org/r/#/c/32700/ for usage.,task_subcomment,See also URL for usage.,SOLUTION USAGE
44919,VisualEditor: Toolbar tooltips should also suggest key-commands,"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",task_description,"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**:
URL",SOLUTION USAGE
195707,VisualEditor: Toolbar tooltips should also suggest key-commands,"Now merged, will go out in 2013-02-04 release cycle.",task_subcomment,"Now merged, will go out in 2013-02-04 release cycle.",SOLUTION USAGE
195705,VisualEditor: Toolbar tooltips should also suggest key-commands,Patched in https://gerrit.wikimedia.org/r/#/c/44347/,task_subcomment,Patched in URL,SOLUTION USAGE
44848,VisualEditor: Notifications should not use db-variant of page titles,"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",task_description,"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",SOLUTION USAGE
191994,VisualEditor: Notifications should not use db-variant of page titles,"(In reply to comment #1)
> Change-Id: Ie84168cd2509a17c180c6143a87a18ae8bbb3d0a
Merged.",task_subcomment,"(In reply to comment #1)
QUOTE
Merged.",ACTION ON ISSUE
191987,VisualEditor: Notifications should not use db-variant of page titles,Change-Id: Ie84168cd2509a17c180c6143a87a18ae8bbb3d0a,task_subcomment,Change-Id: Ie84168cd2509a17c180c6143a87a18ae8bbb3d0a,TASK PROGRESS
44847,VisualEditor: Support Internet Explorer,"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",task_description,"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",SOLUTION DISCUSSION
191955,VisualEditor: Support Internet Explorer,"This is close-enough to done that I'm going to make this as complete. No doubt there will remain bugs, but those are within the framework of VE generally ""working"".",task_subcomment,"This is close-enough to done that I'm going to make this as complete. No doubt there will remain bugs, but those are within the framework of VE generally ""working"".",SOLUTION DISCUSSION
191951,VisualEditor: Support Internet Explorer,Please see Bug 41233,task_subcomment,Please see Bug 41233,ACTION ON ISSUE
191947,VisualEditor: Support Internet Explorer,"Argh, ignore that; an at-least partial fix in gerrit 37592.",task_subcomment,"Argh, ignore that; an at-least partial fix in gerrit 37592.",SOLUTION DISCUSSION
191939,VisualEditor: Support Internet Explorer,Attempted fixes in gerrit 37566 and gerrit 37570.,task_subcomment,Attempted fixes in gerrit 37566 and gerrit 37570.,SOLUTION DISCUSSION
44842,VisualEditor: Create a link at the beginning of the document throws rangy error,"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",task_description,"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",BUG REPRODUCTION
191722,VisualEditor: Create a link at the beginning of the document throws rangy error,Related URL: https://gerrit.wikimedia.org/r/69707 (Gerrit Change I8bcdea0f7a6951216bf8368865d23ef6246880ea),task_subcomment,Related URL: GERRIT_URL (Gerrit Change I8bcdea0f7a6951216bf8368865d23ef6246880ea),TASK PROGRESS
191717,VisualEditor: Create a link at the beginning of the document throws rangy error,Fix in gerrit 37603,task_subcomment,Fix in gerrit 37603,SOLUTION USAGE
44764,"VisualEditor: Pre-parsed messages (minoredit, watchthis) should be in user language instead site language","

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
187052,"VisualEditor: Pre-parsed messages (minoredit, watchthis) should be in user language instead site language",Merged.,task_subcomment,Merged.,SOLUTION DISCUSSION
187047,"VisualEditor: Pre-parsed messages (minoredit, watchthis) should be in user language instead site language",Change-Id: I84fee641162cdeed290092e56fb0e1d2562d833d,task_subcomment,Change-Id: I84fee641162cdeed290092e56fb0e1d2562d833d,ACTION ON ISSUE
44670,VisualEditor: ext.visualEditor.specialMessages module cache invalidation broken,"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",task_description,"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].


QUOTE
QUOTE


URL

Assigning to self, being worked on. Filing as reminder and as future reference.

--------------------------
**Version**: unspecified
**Severity**: major",SOLUTION USAGE
181694,VisualEditor: ext.visualEditor.specialMessages module cache invalidation broken,Now merged into master.,task_subcomment,Now merged into master.,TASK PROGRESS
181687,VisualEditor: ext.visualEditor.specialMessages module cache invalidation broken,Change-Id: I7f26b47e9467e850c08b9c217c4f1098590de109,task_subcomment,Change-Id: I7f26b47e9467e850c08b9c217c4f1098590de109,ACTION ON ISSUE
44456,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"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",task_description,"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",BUG REPRODUCTION
194167,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"I added tests in https://gerrit.wikimedia.org/r/#/c/35388/, which should catch future regressions.",task_subcomment,I added tests in URL which should catch future regressions.,TASK PROGRESS
194165,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"It helps when I actually read the error message, hence the first folic.

Said method can return null, though whether it will for your use case... So it shouldn't do any harm at least",task_subcomment,"It helps when I actually read the error message, hence the first folic.

Said method can return null, though whether it will for your use case... So it shouldn't do any harm at least",SOLUTION DISCUSSION
194161,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"Thanks for fixing this, Sam (also for the wfProfileOuts).

Apparently this was not caught by a parser test, so I'll create some tests for #REDIRECT behavior.

I'll also check whether the ""if ( $target )"" is redundant or not. In any case, it shouldn't do any harm keeping it there.",task_subcomment,"Thanks for fixing this, Sam (also for the wfProfileOuts).

Apparently this was not caught by a parser test, so I'll create some tests for #REDIRECT behavior.

I'll also check whether the ""if ( $target )"" is redundant or not. In any case, it shouldn't do any harm keeping it there.",SOLUTION DISCUSSION
194157,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),https://gerrit.wikimedia.org/r/#/c/35327/,task_subcomment,URL,ACTION ON ISSUE
194150,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"Basic fix in https://gerrit.wikimedia.org/r/#/c/35316/

Not sure if further work also needed",task_subcomment,"Basic fix in URL

Not sure if further work also needed",SOLUTION DISCUSSION
194143,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"http://p.defau.lt/?hOOnMmL6voQcgnoX4_1Gpw

[26-Nov-2012 22:14:15] Fatal error: Call to undefined method Title::getRedirectTarget() at /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php on line 305
Server: mw11
URL: http://[unknown-host]
Backtrace:
#0 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(305): LabeledSectionTransclusion->getWikiPageDom()
#1 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(367): LabeledSectionTransclusion::getWikiPageDom(Object(Title), Array)
#2 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(438): LabeledSectionTransclusion::setupPfunc12(Object(Parser), Object(PPTemplateFrame_DOM), Array, 'lst')
#3 [internal function]: LabeledSectionTransclusion::pfuncIncludeObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#4 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#6 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3452): PPFrame_DOM->expand(Object(PPNode_DOM))
#7 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#8 /usr/local/apache/common-local/php-1.21wmf5/extensions/ParserFunctions/ParserFunctions_body.php(400): PPFrame_DOM->expand(Object(PPNode_DOM))
#9 [internal function]: ExtParserFunctions::ifexistObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#10 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array('ExtParserFuncti...', Array)
#11 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#12 /usr/local/apache/common-local/php-1.21wmf5/extensions/ParserFunctions/ParserFunctions_body.php(400): PPFrame_DOM->expand(Object(PPNode_DOM))
#13 [internal function]: ExtParserFunctions::ifexistObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#14 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array('ExtParserFuncti...', Array)
#15 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#16 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3452): PPFrame_DOM->expand(Object(PPNode_DOM))
#17 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPFrame_DOM))
#18 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3073): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#19 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(1157): Parser->replaceVariables('The Wikimedia F...')
#20 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(385): Parser->internalParse('The Wikimedia F...')
#21 [internal function]: Parser->parse('The Wikimedia F...', Object(Title), Object(ParserOptions), true, true, NULL)
#22 /usr/local/apache/common-local/php-1.21wmf5/includes/StubObject.php(79): call_user_func_array(Array, Array)
#23 /usr/local/apache/common-local/php-1.21wmf5/includes/StubObject.php(99): StubObject->_call('parse', Array)
#24 /usr/local/apache/common-local/php-1.21wmf5/includes/content/WikitextContent.php(290): StubObject->__call('parse', Array)
#25 /usr/local/apache/common-local/php-1.21wmf5/includes/content/WikitextContent.php(290): StubObject->parse('The Wikimedia F...', Object(Title), Object(ParserOptions), true, true, NULL)
#26 /usr/local/apache/common-local/php-1.21wmf5/includes/content/AbstractContent.php(234): WikitextContent->getParserOutput(Object(Title), NULL, NULL, false)
#27 /usr/local/apache/common-local/php-1.21wmf5/includes/job/jobs/RefreshLinksJob.php(81): AbstractContent->getSecondaryDataUpdates(Object(Title), NULL, false)
#28 /usr/local/apache/common-local/php-1.21wmf5/includes/job/jobs/RefreshLinksJob.php(193): RefreshLinksJob::runForTitleInternal(Object(Title), Object(Revision), 'RefreshLinksJob...')
#29 /usr/local/apache/common-local/php-1.21wmf5/maintenance/runJobs.php(83): RefreshLinksJob2->run()
#30 /usr/local/apache/common-local/php-1.21wmf5/maintenance/doMaintenance.php(110): RunJobs->execute()
#31 /usr/local/apache/common-local/php-1.21wmf5/maintenance/runJobs.php(116): require_once('/usr/local/apac...')
#32 /usr/local/apache/common-local/multiversion/MWScript.php(68): require_once('/usr/local/apac...')
#33 {main}",task_subcomment,"URL

[26-Nov-2012 22:14:15] Fatal error: Call to undefined method Title::getRedirectTarget() at /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php on line 305
Server: mw11
URL: URL
Backtrace:
#0 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(305): LabeledSectionTransclusion->getWikiPageDom()
#1 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(367): LabeledSectionTransclusion::getWikiPageDom(Object(Title), Array)
#2 /usr/local/apache/common-local/php-1.21wmf5/extensions/LabeledSectionTransclusion/lst.php(438): LabeledSectionTransclusion::setupPfunc12(Object(Parser), Object(PPTemplateFrame_DOM), Array, 'lst')
#3 [internal function]: LabeledSectionTransclusion::pfuncIncludeObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#4 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array(Array, Array)
#5 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#6 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3452): PPFrame_DOM->expand(Object(PPNode_DOM))
#7 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#8 /usr/local/apache/common-local/php-1.21wmf5/extensions/ParserFunctions/ParserFunctions_body.php(400): PPFrame_DOM->expand(Object(PPNode_DOM))
#9 [internal function]: ExtParserFunctions::ifexistObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#10 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array('ExtParserFuncti...', Array)
#11 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#12 /usr/local/apache/common-local/php-1.21wmf5/extensions/ParserFunctions/ParserFunctions_body.php(400): PPFrame_DOM->expand(Object(PPNode_DOM))
#13 [internal function]: ExtParserFunctions::ifexistObj(Object(Parser), Object(PPTemplateFrame_DOM), Array)
#14 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3286): call_user_func_array('ExtParserFuncti...', Array)
#15 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#16 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3452): PPFrame_DOM->expand(Object(PPNode_DOM))
#17 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Preprocessor_DOM.php(1084): Parser->braceSubstitution(Array, Object(PPFrame_DOM))
#18 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(3073): PPFrame_DOM->expand(Object(PPNode_DOM), 0)
#19 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(1157): Parser->replaceVariables('The Wikimedia F...')
#20 /usr/local/apache/common-local/php-1.21wmf5/includes/parser/Parser.php(385): Parser->internalParse('The Wikimedia F...')
#21 [internal function]: Parser->parse('The Wikimedia F...', Object(Title), Object(ParserOptions), true, true, NULL)
#22 /usr/local/apache/common-local/php-1.21wmf5/includes/StubObject.php(79): call_user_func_array(Array, Array)
#23 /usr/local/apache/common-local/php-1.21wmf5/includes/StubObject.php(99): StubObject->_call('parse', Array)
#24 /usr/local/apache/common-local/php-1.21wmf5/includes/content/WikitextContent.php(290): StubObject->__call('parse', Array)
#25 /usr/local/apache/common-local/php-1.21wmf5/includes/content/WikitextContent.php(290): StubObject->parse('The Wikimedia F...', Object(Title), Object(ParserOptions), true, true, NULL)
#26 /usr/local/apache/common-local/php-1.21wmf5/includes/content/AbstractContent.php(234): WikitextContent->getParserOutput(Object(Title), NULL, NULL, false)
#27 /usr/local/apache/common-local/php-1.21wmf5/includes/job/jobs/RefreshLinksJob.php(81): AbstractContent->getSecondaryDataUpdates(Object(Title), NULL, false)
#28 /usr/local/apache/common-local/php-1.21wmf5/includes/job/jobs/RefreshLinksJob.php(193): RefreshLinksJob::runForTitleInternal(Object(Title), Object(Revision), 'RefreshLinksJob...')
#29 /usr/local/apache/common-local/php-1.21wmf5/maintenance/runJobs.php(83): RefreshLinksJob2->run()
#30 /usr/local/apache/common-local/php-1.21wmf5/maintenance/doMaintenance.php(110): RunJobs->execute()
#31 /usr/local/apache/common-local/php-1.21wmf5/maintenance/runJobs.php(116): require_once('/usr/local/apac...')
#32 /usr/local/apache/common-local/multiversion/MWScript.php(68): require_once('/usr/local/apac...')
#33 {main}",BUG REPRODUCTION
194137,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),Caused by https://gerrit.wikimedia.org/r/#/c/31330/,task_subcomment,Caused by URL,BUG REPRODUCTION
194130,LabeledSectionTransclusion: Fatal error:  Call to undefined method Title::getRedirectTarget(),"Seems to be causing:

* Fatal error where directly on page: https://www.mediawiki.org/w/index.php?title=VisualEditor/Feedback&oldid=597441
* Blank section where transcluded via a Template: https://www.mediawiki.org/w/index.php?title=VisualEditor&oldid=598709",task_subcomment,"Seems to be causing:

* Fatal error where directly on page: URL
* Blank section where transcluded via a Template: URL",BUG REPRODUCTION
44335,VisualEditor: Temporarily add IE to blacklist for December release as CE support is currently insufficient,"

--------------------------
**Version**: unspecified
**Severity**: blocker",task_description,"

--------------------------
**Version**: unspecified
**Severity**: blocker",BUG REPRODUCTION
186736,VisualEditor: Temporarily add IE to blacklist for December release as CE support is currently insufficient,https://gerrit.wikimedia.org/r/#/c/34584/,task_subcomment,URL,ACTION ON ISSUE
44123,VisualEditor: i18n for alien tooltip,"The tooltip on aliens (""Sorry, you can't edit this with the Visual Editor"" or whatever) should be i18ned.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"The tooltip on aliens (""Sorry, you can't edit this with the Visual Editor"" or whatever) should be i18ned.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION USAGE
199634,VisualEditor: i18n for alien tooltip,Fixed in gerrit 33851,task_subcomment,Fixed in gerrit 33851,SOLUTION USAGE
199628,VisualEditor: i18n for alien tooltip,"Also it's VisualEditor not ""Visual Editor"". :-)",task_subcomment,"Also it's VisualEditor not ""Visual Editor"". :-)",SOLUTION USAGE
44120,VisualEditor: Change markers don't propagate when generated paragraphs are unwrapped,"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",task_description,"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",BUG REPRODUCTION
199486,VisualEditor: Change markers don't propagate when generated paragraphs are unwrapped,"

*** This bug has been marked as a duplicate of bug 41947 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 41947 ***",ACTION ON ISSUE
44111,[Regression] Parsoid now wrongly santising wikitext of tables,"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",task_description,"See URL - 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",BUG REPRODUCTION
199059,[Regression] Parsoid now wrongly santising wikitext of tables,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],task_subcomment,[Parsoid component reorg by merging JS/General and General. See bug 50685 for more information. Filter bugmail on this comment. parsoidreorg20130704],ACTION ON ISSUE
199056,[Regression] Parsoid now wrongly santising wikitext of tables,"This is not a regression, and is already tracked. So closing as duplicate.

*** This bug has been marked as a duplicate of bug 39564 ***",task_subcomment,"This is not a regression, and is already tracked. So closing as duplicate.

*** This bug has been marked as a duplicate of bug 39564 ***",ACTION ON ISSUE
199052,[Regression] Parsoid now wrongly santising wikitext of tables,"Are you sure this was edited without us introducing quotes before? Selective serialization is designed to handle this, but so far we have always normalized inter-attribute spacing and quoting.",task_subcomment,"Are you sure this was edited without us introducing quotes before? Selective serialization is designed to handle this, but so far we have always normalized inter-attribute spacing and quoting.",SOLUTION DISCUSSION
56802,"VisualEditor: In the save dialog, ""characters left"" is under the ""pending changes"" text","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",task_description,"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.

URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
270182,"VisualEditor: In the save dialog, ""characters left"" is under the ""pending changes"" text","Merging with bug 52175; this is happily already fixed in the re-written save dialog that will be coming shortly. Sorry for the disruption.

*** This bug has been marked as a duplicate of bug 52175 ***",task_subcomment,"Merging with bug 52175; this is happily already fixed in the re-written save dialog that will be coming shortly. Sorry for the disruption.

*** This bug has been marked as a duplicate of bug 52175 ***",ACTION ON ISSUE
270177,"VisualEditor: In the save dialog, ""characters left"" is under the ""pending changes"" text",Confirmed bug on de.wp.  Support for flagged revs was added on bug 49699.,task_subcomment,Confirmed bug on de.wp.  Support for flagged revs was added on bug 49699.,BUG REPRODUCTION
56728,VisualEditor: Copying a heading's text doesn't copy its format (unless the entire node is copied),"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",task_description,"From T56721 comment 2:

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

--------------------------
**Version**: unspecified
**Severity**: normal",MOTIVATION
265880,VisualEditor: Copying a heading's text doesn't copy its format (unless the entire node is copied),"

*** This bug has been marked as a duplicate of bug 50126 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50126 ***",ACTION ON ISSUE
56727,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"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",task_description,"Currently on MediaWiki.org, categories cannot be removed from the 'Page Settings' modal. This is true of new categories added and existing categories.

URL

Inez says he's working on a fix now.

--------------------------
**Version**: unspecified
**Severity**: major",BUG REPRODUCTION
265842,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86674 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86674",task_subcomment,"Change 86674 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

GERRIT_URL",TASK PROGRESS
265838,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86673 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86673",task_subcomment,"Change 86673 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

GERRIT_URL",TASK PROGRESS
265834,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86674 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86674",task_subcomment,"Change 86674 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

GERRIT_URL",ACTION ON ISSUE
265830,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86673 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86673",task_subcomment,"Change 86673 had a related patch set uploaded by Jforrester:
removedItems[i] is already an item, no need to pass removedItems[i].item

GERRIT_URL",ACTION ON ISSUE
265824,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Marking as ""FIXED""; have removed ""or change sort key"" from title per discussion with Inez.",task_subcomment,"Marking as ""FIXED""; have removed ""or change sort key"" from title per discussion with Inez.",ACTION ON ISSUE
265817,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86341 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

https://gerrit.wikimedia.org/r/86341",task_subcomment,"Change 86341 merged by jenkins-bot:
removedItems[i] is already an item, no need to pass removedItems[i].item

GERRIT_URL",TASK PROGRESS
265813,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86341 had a related patch set uploaded by Catrope:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

https://gerrit.wikimedia.org/r/86341",task_subcomment,"Change 86341 had a related patch set uploaded by Catrope:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

GERRIT_URL",ACTION ON ISSUE
265807,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,Bugfix for removal is waiting for review. Sortkey still not fixed - Trevor: Can you split it into separated bug?,task_subcomment,Bugfix for removal is waiting for review. Sortkey still not fixed - Trevor: Can you split it into separated bug?,TASK PROGRESS
265799,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Change 86341 had a related patch set uploaded by Inez:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

https://gerrit.wikimedia.org/r/86341",task_subcomment,"Change 86341 had a related patch set uploaded by Inez:
(bug 54727) item itself is an item, there is no need to try to pass item of that item

GERRIT_URL",ACTION ON ISSUE
265792,VisualEditor: Can't remove categories from 'Page Settings' modal in latest build,"Also just checked editing a sort key — that functionality is no longer working as well. You can enter text into the field and close the inspector, but when it is reopened the text is not retained.",task_subcomment,"Also just checked editing a sort key — that functionality is no longer working as well. You can enter text into the field and close the inspector, but when it is reopened the text is not retained.",BUG REPRODUCTION
56721,VisualEditor: Header formatting is stripped when copying (or cutting) and pasting inside a single article in Firefox,"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}",task_description,"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 (URL
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}",BUG REPRODUCTION
265480,VisualEditor: Header formatting is stripped when copying (or cutting) and pasting inside a single article in Firefox,"Making this a new bug as it's actually present in all browsers and has been around for a while, unlike this one - bug 54728.",task_subcomment,"Making this a new bug as it's actually present in all browsers and has been around for a while, unlike this one - bug 54728.",BUG REPRODUCTION
265475,VisualEditor: Header formatting is stripped when copying (or cutting) and pasting inside a single article in Firefox,"Oh, it is fixed!  But now I see a more minor issue:

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

I can create a new ticket if you need me to, but I think this one may suffice with a name change.",task_subcomment,"Oh, it is fixed!  But now I see a more minor issue:

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: URL

Everything is retained except the H2 formatting on 'Start'. See this screenshot as an example too: URL

I can create a new ticket if you need me to, but I think this one may suffice with a name change.",BUG REPRODUCTION
265469,VisualEditor: Header formatting is stripped when copying (or cutting) and pasting inside a single article in Firefox,"Aha - yes, sorry, I *can* re-create this in wmf18 (en.wikipedia.org) but not wmf19 (mediawiki.org). I think we fixed this is in gerrit 85213, but closing as FIXED for now. If you can reproduce on MediaWiki.org (or master), please re-open.",task_subcomment,"Aha - yes, sorry, I *can* re-create this in wmf18 (en.wikipedia.org) but not wmf19 (mediawiki.org). I think we fixed this is in gerrit 85213, but closing as FIXED for now. If you can reproduce on MediaWiki.org (or master), please re-open.",ACTION ON ISSUE
56706,VisualEditor: Sometimes the edit link for VE does not appear,"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}",task_description,"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}",BUG REPRODUCTION
264484,VisualEditor: Sometimes the edit link for VE does not appear,No recent reports.,task_subcomment,No recent reports.,ACTION ON ISSUE
264482,VisualEditor: Sometimes the edit link for VE does not appear,"Have you seen this issue recently? If not, this could probably be closed...",task_subcomment,"Have you seen this issue recently? If not, this could probably be closed...",ACTION ON ISSUE
264480,VisualEditor: Sometimes the edit link for VE does not appear,*** Bug 60359 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 60359 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
264477,VisualEditor: Sometimes the edit link for VE does not appear,"probably worth a look but this might be WORKSFORME, I don't think we've encountered this issue in at least a month",task_subcomment,"probably worth a look but this might be WORKSFORME, I don't think we've encountered this issue in at least a month",WORKAROUNDS
264475,VisualEditor: Sometimes the edit link for VE does not appear,"Created attachment 13393
Edit link for VE missing in manual operation

**Attached**: {F12180}",task_subcomment,"Created attachment 13393
Edit link for VE missing in manual operation

**Attached**: {F12180}",ACTION ON ISSUE
56675,VisualEditor: Render lock when changing selection prevents inspectors' changes from rendering,"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",task_description,"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",BUG REPRODUCTION
263009,VisualEditor: Render lock when changing selection prevents inspectors' changes from rendering,"Change 90957 merged by jenkins-bot:
Defer selection-triggered updates in ve.ui.Context

https://gerrit.wikimedia.org/r/90957",task_subcomment,"Change 90957 merged by jenkins-bot:
Defer selection-triggered updates in ve.ui.Context

GERRIT_URL",ACTION ON ISSUE
263005,VisualEditor: Render lock when changing selection prevents inspectors' changes from rendering,"Change 90957 had a related patch set uploaded by Catrope:
Defer selection-triggered updates in ve.ui.Context

https://gerrit.wikimedia.org/r/90957",task_subcomment,"Change 90957 had a related patch set uploaded by Catrope:
Defer selection-triggered updates in ve.ui.Context

GERRIT_URL",ACTION ON ISSUE
263002,VisualEditor: Render lock when changing selection prevents inspectors' changes from rendering,"From #mediawiki-visualeditor IRC with RoanKattouw:

* It seems wrong to implement click-out-to-close by detecting a selection change.
* Should we bind to document mousedown instead? We need to avoid tripping over other mouse handling of course.

Aside from this,

* In general DM selection changes should emit something less drastic than 'change', because we don't want them to get back to the CE layer (which has a somewhat different set of possible cursor positions).
* I (David) am currently working on a fairly big refactor of ve.ce.Surface will include this.",task_subcomment,"From #mediawiki-visualeditor IRC with RoanKattouw:

* It seems wrong to implement click-out-to-close by detecting a selection change.
* Should we bind to document mousedown instead? We need to avoid tripping over other mouse handling of course.

Aside from this,

* In general DM selection changes should emit something less drastic than 'change', because we don't want them to get back to the CE layer (which has a somewhat different set of possible cursor positions).
* I (David) am currently working on a fairly big refactor of ve.ce.Surface will include this.",SOLUTION DISCUSSION
56577,VisualEditor: Rendering of  MWExtensionNode is empty after the user edits it,"1. Create a page with some content here
2. Edit the page in VE. Note that the  tag renders correctly
3. Use the alien tag inspector to edit the contents of the  tag
4. The  tag rerenders as an empty block

This is because the HTML  tag is self-closing and cannot have any content. This leads to strange situations like:

>>> extensionNode[0]
​whee​​
>>> extensionNode[0].outerHTML
""""

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",task_description,"1. Create a page with some content here
2. Edit the page in VE. Note that the  tag renders correctly
3. Use the alien tag inspector to edit the contents of the  tag
4. The  tag rerenders as an empty block

This is because the HTML  tag is self-closing and cannot have any content. This leads to strange situations like:

QUOTE
​whee​​
QUOTE
""""

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**:
URL",BUG REPRODUCTION
257051,VisualEditor: Rendering of  MWExtensionNode is empty after the user edits it,"Change 98392 merged by jenkins-bot:
Render MW extension node wikitext with XML

https://gerrit.wikimedia.org/r/98392",task_subcomment,"Change 98392 merged by jenkins-bot:
Render MW extension node wikitext with XML

GERRIT_URL",ACTION ON ISSUE
257044,VisualEditor: Rendering of  MWExtensionNode is empty after the user edits it,"Change 98392 had a related patch set uploaded by Esanders:
Render MW extension node wikitext with XML

https://gerrit.wikimedia.org/r/98392",task_subcomment,"Change 98392 had a related patch set uploaded by Esanders:
Render MW extension node wikitext with XML

GERRIT_URL",SOLUTION USAGE
56445,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","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",task_description,"URL

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
URL",SOLUTION USAGE
254458,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","Hey Roan :)
I might be wrong, but I think it's still about name corruption (I think the user is complaining that he added or reused a reference, but after he saved the number in brackets was not pointing to the one he chose).
Anyway, I'll contact the user to get more details, because it might also be not a bug at all. As I wrote elsewhere, I think it can be confusing that the name and the number of a reference do not match, although everything will still work as intended.
See
https://en.wikipedia.org/w/index.php?title=User%3AElitre_%28WMF%29%2FSandbox&diff=575128343&oldid=575128003
(the reference #2 gets a ref name:3).",task_subcomment,"Hey Roan :)
I might be wrong, but I think it's still about name corruption (I think the user is complaining that he added or reused a reference, but after he saved the number in brackets was not pointing to the one he chose).
Anyway, I'll contact the user to get more details, because it might also be not a bug at all. As I wrote elsewhere, I think it can be confusing that the name and the number of a reference do not match, although everything will still work as intended.
See
URL
(the reference #2 gets a ref name:3).",BUG REPRODUCTION
254456,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","(In reply to comment #7)
> Additional comments from Polish Wikipedia Kthaara:
> 
> ""Bug seems did not recognize references or not recognize their numbers. Ex.:
> I
> wrote some text in section about add-ons and need to make a reference to page
> from Eve-community. I make one and VE, sure, did it, but aotomaticaly
> redirects
> to completely different reference, like: it make ref no. 50 and redirect it
> to
> no. 3 - which is different thing. After several tries I manage to get right
> reference but it change another. In this moment I gave up."" 
> 
> And here is a diff:
> https://pl.wikipedia.org/w/index.
> php?title=Eve_Online&diff=37587971&oldid=37587957
This looks like a similar bug, but it's not the same bug (the original report was about name corruption, not content corruption). Could you file a new bug for this?

Additionally, an as detailed as possible explanation of what the user did to produce that diff (step-by-step instructions, if they remember) would be very helpful. It's theoretically possible for VE to produce that diff legitimately if the user did certain things, but I doubt that's what happened.",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
This looks like a similar bug, but it's not the same bug (the original report was about name corruption, not content corruption). Could you file a new bug for this?

Additionally, an as detailed as possible explanation of what the user did to produce that diff (step-by-step instructions, if they remember) would be very helpful. It's theoretically possible for VE to produce that diff legitimately if the user did certain things, but I doubt that's what happened.",INVESTIGATION AND EXPLORATION
254454,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","Additional comments from Polish Wikipedia Kthaara:

""Bug seems did not recognize references or not recognize their numbers. Ex.: I wrote some text in section about add-ons and need to make a reference to page from Eve-community. I make one and VE, sure, did it, but aotomaticaly redirects to completely different reference, like: it make ref no. 50 and redirect it to no. 3 - which is different thing. After several tries I manage to get right reference but it change another. In this moment I gave up."" 

And here is a diff: https://pl.wikipedia.org/w/index.php?title=Eve_Online&diff=37587971&oldid=37587957",task_subcomment,"Additional comments from Polish Wikipedia Kthaara:

""Bug seems did not recognize references or not recognize their numbers. Ex.: I wrote some text in section about add-ons and need to make a reference to page from Eve-community. I make one and VE, sure, did it, but aotomaticaly redirects to completely different reference, like: it make ref no. 50 and redirect it to no. 3 - which is different thing. After several tries I manage to get right reference but it change another. In this moment I gave up."" 

And here is a diff: URL",BUG REPRODUCTION
254452,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","This problem was also reported happening on Polish Wikipedia (PL.WP) by User:Kthaara (using VE on Win 7, Mozilla Firefox (latest version)).

https://pl.wikipedia.org/wiki/Wikipedia:VisualEditor/Opinie#linki_i_przypisy 

>> This bug appears when I edited Eve Online page:
>> https://pl.wikipedia.org/wiki/Eve_Online",task_subcomment,"This problem was also reported happening on Polish Wikipedia (PL.WP) by User:Kthaara (using VE on Win 7, Mozilla Firefox (latest version)).

URL 

QUOTE
QUOTE",MOTIVATION
254448,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","I believe that this is the same as bug 54341 which was fixed last week and is live.

*** This bug has been marked as a duplicate of bug 54341 ***",task_subcomment,"I believe that this is the same as bug 54341 which was fixed last week and is live.

*** This bug has been marked as a duplicate of bug 54341 ***",BUG REPRODUCTION
254443,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","More from Red Fiona:
<>",task_subcomment,"More from Red Fiona:
<>",BUG REPRODUCTION
254439,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","Worse, I just attempted to add an actual reference, and this bug just replaced the reference I tried to insert with a cross-reference to this new bogus :0 reference!

It was a good thing Visual Editor got disabled by default recently - quality control seems to be lacking!!",task_subcomment,"Worse, I just attempted to add an actual reference, and this bug just replaced the reference I tried to insert with a cross-reference to this new bogus :0 reference!

It was a good thing Visual Editor got disabled by default recently - quality control seems to be lacking!!",BUG REPRODUCTION
254431,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","Created attachment 13346
Screenshot of dirty diff on ""Turkey Hill (company)""

https://en.wikipedia.org/w/index.php?title=Turkey_Hill_(company)&oldid=568325662&veaction=edit

http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-09-17_13-00/Turkey_Hill_-company-.png

**Attached**: {F11869}",task_subcomment,"Created attachment 13346
Screenshot of dirty diff on ""Turkey Hill (company)""

URL

URL

**Attached**: {F11869}",BUG REPRODUCTION
254424,"[Regression] VisualEditor: Attribute name="":0"" inserted into ","Created attachment 13344
Screenshot of dirty diff on ""Daniel Rowe (footballer)""

http://tools.wmflabs.org/visualeditor/dirtydiffs/2013-09-17_13-00/Daniel_Rowe_-footballer-.png

**Attached**: {F11868}",task_subcomment,"Created attachment 13344
Screenshot of dirty diff on ""Daniel Rowe (footballer)""

URL

**Attached**: {F11868}",BUG REPRODUCTION
56443,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"**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",task_description,"**Author:** CODE

**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",BUG REPRODUCTION
254347,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86801 merged by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86801",task_subcomment,"Change 86801 merged by Catrope:
Make cursoring over a FocusableNode work again

GERRIT_URL",ACTION ON ISSUE
254339,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86800 merged by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86800",task_subcomment,"Change 86800 merged by Catrope:
Make cursoring over a FocusableNode work again

GERRIT_URL",ACTION ON ISSUE
254336,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,Merged into master; we'll back-port and deploy tomorrow.,task_subcomment,Merged into master; we'll back-port and deploy tomorrow.,SOLUTION USAGE
254332,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86801 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86801",task_subcomment,"Change 86801 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

GERRIT_URL",TASK PROGRESS
254330,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86800 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86800",task_subcomment,"Change 86800 had a related patch set uploaded by Jforrester:
Make cursoring over a FocusableNode work again

GERRIT_URL",TASK PROGRESS
254326,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86788 merged by jenkins-bot:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86788",task_subcomment,"Change 86788 merged by jenkins-bot:
Make cursoring over a FocusableNode work again

GERRIT_URL",ACTION ON ISSUE
254322,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,"Change 86788 had a related patch set uploaded by Catrope:
Make cursoring over a FocusableNode work again

https://gerrit.wikimedia.org/r/86788",task_subcomment,"Change 86788 had a related patch set uploaded by Catrope:
Make cursoring over a FocusableNode work again

GERRIT_URL",TASK PROGRESS
254318,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,*** Bug 54722 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54722 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
254314,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,The events from the pasteTarget (which has focus when a focusableNode is selected) are not getting through to the document listener.,task_subcomment,The events from the pasteTarget (which has focus when a focusableNode is selected) are not getting through to the document listener.,BUG REPRODUCTION
254307,VisualEditor: Cursor cannot move past references (or other nodes) when using arrow keys,Updating priority to normal. Inability to move the cursor using arrows is definitely a bug.,task_subcomment,Updating priority to normal. Inability to move the cursor using arrows is definitely a bug.,BUG REPRODUCTION
56410,VisualEditor: [Regression] Copy/paste of existing templates and images broken (unformatted text pasted only),"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",task_description,"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. URL

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**:
URL",BUG REPRODUCTION
252365,VisualEditor: [Regression] Copy/paste of existing templates and images broken (unformatted text pasted only),This was fixed some time ago; sorry for the slow update.,task_subcomment,This was fixed some time ago; sorry for the slow update.,SOLUTION USAGE
56406,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Parsoid is flooding the global job queue.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: [see comment 9]",task_description,"Parsoid is flooding the global job queue.

--------------------------
**Version**: wmf-deployment
**Severity**: normal
**Whiteboard**: [see comment 9]",BUG REPRODUCTION
252161,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to James Forrester from comment #36)
> Can we close this bug now? I believe this has been fixed.

No feedback => Closing.",task_subcomment,"(In reply to James Forrester from comment #36)
QUOTE

No feedback => Closing.",ACTION ON ISSUE
252157,Parsoid jobs are not dequeued fast enough during heavy editing activity,Can we close this bug now? I believe this has been fixed.,task_subcomment,Can we close this bug now? I believe this has been fixed.,ACTION ON ISSUE
252153,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Change 86745 merged by Faidon Liambotis:
Bug 54406: Speed up Parsoid job processing

https://gerrit.wikimedia.org/r/86745",task_subcomment,"Change 86745 merged by Faidon Liambotis:
Bug 54406: Speed up Parsoid job processing

GERRIT_URL",TASK PROGRESS
252150,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #30)
> @MZMcBride: I think both the broader technical and the social issue have been
> discussed sufficiently now. From now on I am not going to discuss anything
> but the Parsoid job queue length in this bug.

I was repeatedly called out (by you and others) on this bug for causing the increased job queue length when there's no evidence this was the case.

(In reply to comment #32)
> (I'm removing myself from cc as we don't even manage to get a fact-based
> summary.)

I wish I could remove myself, but Bugzilla doesn't allow the reporter to be changed. :-(",task_subcomment,"(In reply to comment #30)
QUOTE
QUOTE
QUOTE

I was repeatedly called out (by you and others) on this bug for causing the increased job queue length when there's no evidence this was the case.

(In reply to comment #32)
QUOTE
QUOTE

I wish I could remove myself, but Bugzilla doesn't allow the reporter to be changed. :-(",ACTION ON ISSUE
252146,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Change 86745 had a related patch set uploaded by GWicke:
Bug 54406: Speed up Parsoid job processing

https://gerrit.wikimedia.org/r/86745",task_subcomment,"Change 86745 had a related patch set uploaded by GWicke:
Bug 54406: Speed up Parsoid job processing

GERRIT_URL",SOLUTION USAGE
252143,Parsoid jobs are not dequeued fast enough during heavy editing activity,(I'm removing myself from cc as we don't even manage to get a fact-based summary.),task_subcomment,(I'm removing myself from cc as we don't even manage to get a fact-based summary.),ACTION ON ISSUE
252140,Parsoid jobs are not dequeued fast enough during heavy editing activity,PS: There is no such thing as a global job queue. There are several independent queues which are stored on the same infrastructure and graphed as an aggregate.,task_subcomment,PS: There is no such thing as a global job queue. There are several independent queues which are stored on the same infrastructure and graphed as an aggregate.,SOLUTION DISCUSSION
252136,Parsoid jobs are not dequeued fast enough during heavy editing activity,@MZMcBride: I think both the broader technical and the social issue have been discussed sufficiently now. From now on I am not going to discuss anything but the Parsoid job queue length in this bug. Please discuss other aspects elsewhere.,task_subcomment,SCREEN_NAME: I think both the broader technical and the social issue have been discussed sufficiently now. From now on I am not going to discuss anything but the Parsoid job queue length in this bug. Please discuss other aspects elsewhere.,ACTION ON ISSUE
252132,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #3)
> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

It's difficult to look at these claims as being anything other than spurious. Attachment 13412 shows a continued increase in the global job queue (now exceeding 3.78 million jobs).

I'm restoring the original bug summary, which was most accurate: Parsoid is flooding the global job queue. Nobody seems to be particularly concerned with this, however, so it may make sense to mark this bug as resolved/worksforme.",task_subcomment,"(In reply to comment #3)
QUOTE
QUOTE

It's difficult to look at these claims as being anything other than spurious. Attachment 13412 shows a continued increase in the global job queue (now exceeding 3.78 million jobs).

I'm restoring the original bug summary, which was most accurate: Parsoid is flooding the global job queue. Nobody seems to be particularly concerned with this, however, so it may make sense to mark this bug as resolved/worksforme.",SOLUTION USAGE
252125,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Created attachment 13412
Screenshot to accompany comment 3

**Attached**: {F11775}",task_subcomment,"Created attachment 13412
Screenshot to accompany comment 3

**Attached**: {F11775}",ATTACHMENT
252118,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #23)
> Just curious - is there anything actionable that can possibly come out of
> this bug?

This bug was filed under the assumption that job queues shouldn't contain millions of jobs.

Gabriel seems to suggest throughout this bug report that the global job queue size is irrelevant (or rather, that he's apparently unconcerned with its size), so I'm not sure there is anything actionable here. This may be a wontfix.

(In reply to comment #21)
> For templates there is no way around the load this creates when they really
> need to be edited. I have a hard time seeing a similarly good reason for
> making 8 million null edits at a rate of ~4/second.

There are a lot of pages to edit. If we edited one page per minute and edited 31,000,000 pages, that would take approximately 58.9 years. Obviously we're going to have to go a bit faster than that.

Many pages have not been re-parsed or purged from cache in years (since 2005 for the oldest pages). This results in outdated or incorrect *links entries, stale HTML cache, etc., in addition to a number of lurking page text anomalies (incorrectly unsubstituted templates, incorrectly unexpanded user signatures, etc.). Null editing is built in to MediaWiki to address these issues on a per-page basis. You've yet to identify any issue with using this built-in feature.

Other than a global job queue that's already flooded, were there any issues from null editing that you (Gabriel) or anyone else has found? If so, I'd like to learn more so that I can understand and grow as a contributor.",task_subcomment,"(In reply to comment #23)
QUOTE
QUOTE

This bug was filed under the assumption that job queues shouldn't contain millions of jobs.

Gabriel seems to suggest throughout this bug report that the global job queue size is irrelevant (or rather, that he's apparently unconcerned with its size), so I'm not sure there is anything actionable here. This may be a wontfix.

(In reply to comment #21)
QUOTE
QUOTE
QUOTE

There are a lot of pages to edit. If we edited one page per minute and edited 31,000,000 pages, that would take approximately 58.9 years. Obviously we're going to have to go a bit faster than that.

Many pages have not been re-parsed or purged from cache in years (since 2005 for the oldest pages). This results in outdated or incorrect *links entries, stale HTML cache, etc., in addition to a number of lurking page text anomalies (incorrectly unsubstituted templates, incorrectly unexpanded user signatures, etc.). Null editing is built in to MediaWiki to address these issues on a per-page basis. You've yet to identify any issue with using this built-in feature.

Other than a global job queue that's already flooded, were there any issues from null editing that you (Gabriel) or anyone else has found? If so, I'd like to learn more so that I can understand and grow as a contributor.",SOLUTION DISCUSSION
252112,Parsoid jobs are not dequeued fast enough during heavy editing activity,"@Yuvi: For the technical part, see comment #9. The social / DoS prevention issue is probably better discussed elsewhere.",task_subcomment,"SCREEN_NAME: For the technical part, see comment #9. The social / DoS prevention issue is probably better discussed elsewhere.",ACTION ON ISSUE
252107,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #24)
> Yes! I'm hoping for a definition of ""what is the problem"" to actually come
> out
> of it. It may take a hundred more comments though, given the current speed
> we're approaching it at.

May I suggest using something that's not bugzilla for that purpose? I understand the need for clarity, but honestly a bugzilla ticket is probably not the best way to do it. A mailing list post, perhaps?",task_subcomment,"(In reply to comment #24)
QUOTE
QUOTE
QUOTE
QUOTE

May I suggest using something that's not bugzilla for that purpose? I understand the need for clarity, but honestly a bugzilla ticket is probably not the best way to do it. A mailing list post, perhaps?",ACTION ON ISSUE
252100,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #23)
> Just curious - is there anything actionable that can possibly come out of
> this
> bug?

Yes! I'm hoping for a definition of ""what is the problem"" to actually come out of it. It may take a hundred more comments though, given the current speed we're approaching it at.",task_subcomment,"(In reply to comment #23)
QUOTE
QUOTE
QUOTE

Yes! I'm hoping for a definition of ""what is the problem"" to actually come out of it. It may take a hundred more comments though, given the current speed we're approaching it at.",SOLUTION DISCUSSION
252093,Parsoid jobs are not dequeued fast enough during heavy editing activity,Just curious - is there anything actionable that can possibly come out of this bug?,task_subcomment,Just curious - is there anything actionable that can possibly come out of this bug?,FUTURE PLAN
252088,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #21)
> Popular templates are protected for a reason, and editors don't edit them
> needlessly, as they know about the high load this causes. 
> 
> For templates there is no way around the load this creates when they really
> need to be edited. 

Ok, so people avoid things which cause overload but still in July we had about 2M additional job queue items. And it seems that's fine. What's not fine then, what is this bug about? Can we please identify the problem and the source of it? Otherwise I don't see how one can identify solutions.

> I have a hard time seeing a similarly good reason for
> making
> 8 million null edits at a rate of ~4/second. 

I'm having a hard time too. They are just speculations without answers to what above.

> Especially without talking to
> the
> people responsible for keeping the site running 

(This makes sense.)

> and in contravention of the
> bot
> policy.

Sigh. There isn't any contravention of the bot policy. The relevant local page is [[Wikipedia:Don't worry about performance]].
Hint: the policies or pseudo-policies you are looking for are on wikitech, e.g. [[wikitech:Robot policy]]. I don't remember which one precisely but there is one written by Tim which explicitly says ""if you're causing problems/bringing the site down we'll block you"", period.
In this case however, I still don't see what the problem is. Again, why is 2M not a problem but 3M yes?",task_subcomment,"(In reply to comment #21)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Ok, so people avoid things which cause overload but still in July we had about 2M additional job queue items. And it seems that's fine. What's not fine then, what is this bug about? Can we please identify the problem and the source of it? Otherwise I don't see how one can identify solutions.

QUOTE
QUOTE
QUOTE

I'm having a hard time too. They are just speculations without answers to what above.

QUOTE
QUOTE
QUOTE

(This makes sense.)

QUOTE
QUOTE
QUOTE

Sigh. There isn't any contravention of the bot policy. The relevant local page is [[Wikipedia:Don't worry about performance]].
Hint: the policies or pseudo-policies you are looking for are on wikitech, e.g. [[wikitech:Robot policy]]. I don't remember which one precisely but there is one written by Tim which explicitly says ""if you're causing problems/bringing the site down we'll block you"", period.
In this case however, I still don't see what the problem is. Again, why is 2M not a problem but 3M yes?",SOLUTION DISCUSSION
252082,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #20)
> Can you then explain why ""the
> second million was too much"", i.e. why reaching 2M job queue is in your
> opinion
> all fine and normal while 3 is something absolutely horrible and criminal?
> Thanks.

Popular templates are protected for a reason, and editors don't edit them needlessly, as they know about the high load this causes. 

For templates there is no way around the load this creates when they really need to be edited. I have a hard time seeing a similarly good reason for making 8 million null edits at a rate of ~4/second. Especially without talking to the people responsible for keeping the site running and in contravention of the bot policy.",task_subcomment,"(In reply to comment #20)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Popular templates are protected for a reason, and editors don't edit them needlessly, as they know about the high load this causes. 

For templates there is no way around the load this creates when they really need to be edited. I have a hard time seeing a similarly good reason for making 8 million null edits at a rate of ~4/second. Especially without talking to the people responsible for keeping the site running and in contravention of the bot policy.",ACTION ON ISSUE
252075,Parsoid jobs are not dequeued fast enough during heavy editing activity,"I'm not sure how familiar you are with the actual writing and enacting of those social rules, but surely here nothing was done against them. The social rules in the various variations of the global [[m:Bot policy]] are not about performance; the speed limit is typically driven by users not wanting their Special:RecentChanges and Special:WatchList to be flooded, which in this case obviously didn't happen (so let's not even start debating what's an ""edit"").

Besides, I don't really have an answer yet to my question, though we're getting nearer; probably it would be faster if we avoided off-topic discussions on alleged abuse and similar stuff.

(In reply to comment #19)
> (In reply to comment #15)
> > I still see no answer about what the spike on July 29 was: are you saying it
> > wasn't about parsoid, but just a coincidence? Or that it was normal to queue
> > over a million jobs in a couple of days (initial caching of all pages or
> > something?) but the second million was too much?
> 
> Just editing a handful really popular templates (some are used in >7 million
> articles) can enqueue a lot of jobs (10 titles per job, so ~700k jobs). As
> can
> editing content at high rates. Core happens to cap the number of titles to
> re-render at 200k, while Parsoid re-renders all, albeit with a delay.

Thanks, so I guess the answer is the second. Can you then explain why ""the second million was too much"", i.e. why reaching 2M job queue is in your opinion all fine and normal while 3 is something absolutely horrible and criminal? Thanks.",task_subcomment,"I'm not sure how familiar you are with the actual writing and enacting of those social rules, but surely here nothing was done against them. The social rules in the various variations of the global [[m:Bot policy]] are not about performance; the speed limit is typically driven by users not wanting their Special:RecentChanges and Special:WatchList to be flooded, which in this case obviously didn't happen (so let's not even start debating what's an ""edit"").

Besides, I don't really have an answer yet to my question, though we're getting nearer; probably it would be faster if we avoided off-topic discussions on alleged abuse and similar stuff.

(In reply to comment #19)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Thanks, so I guess the answer is the second. Can you then explain why ""the second million was too much"", i.e. why reaching 2M job queue is in your opinion all fine and normal while 3 is something absolutely horrible and criminal? Thanks.",ACTION ON ISSUE
252069,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #15)
> I still see no answer about what the spike on July 29 was: are you saying it
> wasn't about parsoid, but just a coincidence? Or that it was normal to queue
> over a million jobs in a couple of days (initial caching of all pages or
> something?) but the second million was too much?

Just editing a handful really popular templates (some are used in >7 million articles) can enqueue a lot of jobs (10 titles per job, so ~700k jobs). As can editing content at high rates. Core happens to cap the number of titles to re-render at 200k, while Parsoid re-renders all, albeit with a delay.

Ideally we'd prioritize direct edits over template updates as only the former has any performance impact. Editing a page with slightly out-of-date template rendering will still yield correct results. Longer-term our goal is to reduce API requests further so that we can run the Parsoid cluster at capacity without taking out the API.

And yes, I was referring to very straightforward social rules that are designed to prevent our users from overloading the site with expensive operations. We currently provide powerful API access that can easily be abused. If the attitude that everything that is not technically blocked must surely be ok becomes more popular we'll have to neuter those APIs significantly. Maybe it is actually time to technically enforce social rules more strictly, for example by automatically blocking abusers.",task_subcomment,"(In reply to comment #15)
QUOTE
QUOTE
QUOTE
QUOTE

Just editing a handful really popular templates (some are used in >7 million articles) can enqueue a lot of jobs (10 titles per job, so ~700k jobs). As can editing content at high rates. Core happens to cap the number of titles to re-render at 200k, while Parsoid re-renders all, albeit with a delay.

Ideally we'd prioritize direct edits over template updates as only the former has any performance impact. Editing a page with slightly out-of-date template rendering will still yield correct results. Longer-term our goal is to reduce API requests further so that we can run the Parsoid cluster at capacity without taking out the API.

And yes, I was referring to very straightforward social rules that are designed to prevent our users from overloading the site with expensive operations. We currently provide powerful API access that can easily be abused. If the attitude that everything that is not technically blocked must surely be ok becomes more popular we'll have to neuter those APIs significantly. Maybe it is actually time to technically enforce social rules more strictly, for example by automatically blocking abusers.",SOLUTION DISCUSSION
252065,Parsoid jobs are not dequeued fast enough during heavy editing activity,"No user in the ""bot"" user group was used to null edit. Just a standard and unprivileged (albeit autoconfirmed) account.

On Wikimedia wikis, 'edit' is rate-limited only for 'ip' and 'newbie', but not for 'user' or 'bot' or any other group, as far as I can tell.",task_subcomment,"No user in the ""bot"" user group was used to null edit. Just a standard and unprivileged (albeit autoconfirmed) account.

On Wikimedia wikis, 'edit' is rate-limited only for 'ip' and 'newbie', but not for 'user' or 'bot' or any other group, as far as I can tell.",MOTIVATION
252059,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #16)
> (In reply to comment #14)
> > Bots are explicitly not rate-limited.
> 
> https://en.wikipedia.org/wiki/Wikipedia:Bot_policy#Bot_requirements states
> that
> ""bots doing non-urgent tasks may edit approximately once every ten seconds"". 
> Am I missing something?

That requirement is imposed by the community, it is not necessarily a technical limit. If you look at https://en.wikipedia.org/wiki/Special:ListGroupRights, the 'bot' group is deliberately exempted from rate limits with the 'noratelimit' userright.",task_subcomment,"(In reply to comment #16)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That requirement is imposed by the community, it is not necessarily a technical limit. If you look at URL the 'bot' group is deliberately exempted from rate limits with the 'noratelimit' userright.",ACTION ON ISSUE
252051,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #14)
> Bots are explicitly not rate-limited.

https://en.wikipedia.org/wiki/Wikipedia:Bot_policy#Bot_requirements states that ""bots doing non-urgent tasks may edit approximately once every ten seconds"". 
Am I missing something?",task_subcomment,"(In reply to comment #14)
QUOTE

URL states that ""bots doing non-urgent tasks may edit approximately once every ten seconds"". 
Am I missing something?",SOLUTION DISCUSSION
252044,Parsoid jobs are not dequeued fast enough during heavy editing activity,"I still see no answer about what the spike on July 29 was: are you saying it wasn't about parsoid, but just a coincidence? Or that it was normal to queue over a million jobs in a couple of days (initial caching of all pages or something?) but the second million was too much?

The new summary seems incorrect in two ways:
1) ""fast enough"" might be incorrect, you say that it's not important if it's slow,
2) ""during heavy bot activity"" is a possibly incorrect guess.
What's sure is that we no longer seem to have any meaningful job queue data.",task_subcomment,"I still see no answer about what the spike on July 29 was: are you saying it wasn't about parsoid, but just a coincidence? Or that it was normal to queue over a million jobs in a couple of days (initial caching of all pages or something?) but the second million was too much?

The new summary seems incorrect in two ways:
1) ""fast enough"" might be incorrect, you say that it's not important if it's slow,
2) ""during heavy bot activity"" is a possibly incorrect guess.
What's sure is that we no longer seem to have any meaningful job queue data.",INVESTIGATION AND EXPLORATION
252037,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #13)
> Still, to avoid any misunderstandings: Null editing at rates way higher than
> those allowed for bots is at best a very bad idea.

Bots are explicitly not rate-limited.",task_subcomment,"(In reply to comment #13)
QUOTE
QUOTE

Bots are explicitly not rate-limited.",ACTION ON ISSUE
252030,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Changed the subject to be more accurate. Some more clarification for those less familiar with the way Parsoid caching works:

* Timely Parsoid cache refreshes are not needed for correctness. Delayed updates can result in a higher percentage of cache misses than usual, but will not result in incorrect edits.

* Parsoid uses its own queue, so a backlog does not affect any other job queue.

So in the bigger picture this is annoying, but not critical.

Still, to avoid any misunderstandings: Null editing at rates way higher than those allowed for bots is at best a very bad idea.",task_subcomment,"Changed the subject to be more accurate. Some more clarification for those less familiar with the way Parsoid caching works:

* Timely Parsoid cache refreshes are not needed for correctness. Delayed updates can result in a higher percentage of cache misses than usual, but will not result in incorrect edits.

* Parsoid uses its own queue, so a backlog does not affect any other job queue.

So in the bigger picture this is annoying, but not critical.

Still, to avoid any misunderstandings: Null editing at rates way higher than those allowed for bots is at best a very bad idea.",SOLUTION DISCUSSION
252023,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #10)
> (In reply to comment #9)
> > Since
> > that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k
> > jobs).
> 
> Did the other jobs increase then? 

Jobs in other job queues (I see 26k refreshlinks2 jobs on enwiki for example), and/or Parsoid jobs on other wikis have likely slightly increased in number. Overall the queue size has slightly decreased since the null-editing was stopped.",task_subcomment,"(In reply to comment #10)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Jobs in other job queues (I see 26k refreshlinks2 jobs on enwiki for example), and/or Parsoid jobs on other wikis have likely slightly increased in number. Overall the queue size has slightly decreased since the null-editing was stopped.",SOLUTION DISCUSSION
252017,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #9)
> It seems that the Parsoid dequeue rate was slightly lower than the average
> enqueue rate since the end of July, which allowed the job backlog to build
> up a bit.

A bit? Looking at https://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=hume.wikimedia.org&v=823574&m=Global_JobQueue_length&r=hour&z=default&jr=&js=&st=1365625056&z=large it seems like the queue went from 355,850 to 1,590,000 in the span of about six days (from July 29 to August 3). It grew by... 346%? That's what you're calling ""a bit""?",task_subcomment,"(In reply to comment #9)
QUOTE
QUOTE
QUOTE

A bit? Looking at URL it seems like the queue went from 355,850 to 1,590,000 in the span of about six days (from July 29 to August 3). It grew by... 346%? That's what you're calling ""a bit""?",SOLUTION DISCUSSION
252009,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #9)
> Since
> that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k
> jobs).

Did the other jobs increase then? The total job queue was 3.01M and is now 2.94M (it generally goes down in European nights and so).",task_subcomment,"(In reply to comment #9)
QUOTE
QUOTE
QUOTE

Did the other jobs increase then? The total job queue was 3.01M and is now 2.94M (it generally goes down in European nights and so).",TASK PROGRESS
252002,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #6)
> (In reply to comment #3)
> > We dequeue Parsoid jobs in a throttled manner to avoid overloading the API
> > during edit spikes. This means that abnormal edit rates especially to
> > templates can create a large backlog of jobs in the Parsoid queue.
> 
> Where does Parsoid fit in to the general MediaWiki ecosystem? Are Parsoid
> jobs
> generated on every edit? If so, why? 

After an edit, the Parsoid HTML for each affected article is generated / updated with jobs that perform HTTP requests to the Parsoid cluster. This ensures that requests from VisualEditor and other users are normally served straight from cache. We have been processing all edits from all Wikipedias since June. As expected, VE deployments have not made a noticeable difference to the load on the Parsoid cluster.

It seems that the Parsoid dequeue rate was slightly lower than the average enqueue rate since the end of July, which allowed the job backlog to build up a bit. During MZMcBride's null edit episode the backlog doubled in size. Since that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k jobs).

So overall, the Parsoid job dequeue rate is slightly too low to absorb abnormal edit rates in a timely manner. It might be sufficient to slightly de-throttle the Parsoid dequeue rate while keeping an eye on the API cluster load (https://ganglia.wikimedia.org/latest/?r=hour&cs=&ce=&m=cpu_report&s=by+name&c=API+application+servers+eqiad&h=&host_regex=&max_graphs=0&tab=m&vn=&sh=1&z=small&hc=4).",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

After an edit, the Parsoid HTML for each affected article is generated / updated with jobs that perform HTTP requests to the Parsoid cluster. This ensures that requests from VisualEditor and other users are normally served straight from cache. We have been processing all edits from all Wikipedias since June. As expected, VE deployments have not made a noticeable difference to the load on the Parsoid cluster.

It seems that the Parsoid dequeue rate was slightly lower than the average enqueue rate since the end of July, which allowed the job backlog to build up a bit. During MZMcBride's null edit episode the backlog doubled in size. Since that stopped yesterday, the enwiki Parsoid job queue has drained by 10% (200k jobs).

So overall, the Parsoid job dequeue rate is slightly too low to absorb abnormal edit rates in a timely manner. It might be sufficient to slightly de-throttle the Parsoid dequeue rate while keeping an eye on the API cluster load (URL",SOLUTION DISCUSSION
251997,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #7)
> Created attachment 13342 [details]
> Screenshot to accompany comment 2

The spike around July 29 is easy to see and most likely corresponds with the deployment mentioned in comment 2. There are also spikes around August 14 and September 8, neither of which have been accounted for yet.

**Attached**: {F11772}",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE

The spike around July 29 is easy to see and most likely corresponds with the deployment mentioned in comment 2. There are also spikes around August 14 and September 8, neither of which have been accounted for yet.

**Attached**: {F11772}",INVESTIGATION AND EXPLORATION
251992,Parsoid jobs are not dequeued fast enough during heavy editing activity,"Created attachment 13342
Screenshot to accompany comment 2

**Attached**: {F11772}",task_subcomment,"Created attachment 13342
Screenshot to accompany comment 2

**Attached**: {F11772}",ATTACHMENT
251986,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #3)
> We dequeue Parsoid jobs in a throttled manner to avoid overloading the API
> during edit spikes. This means that abnormal edit rates especially to
> templates can create a large backlog of jobs in the Parsoid queue.

Where does Parsoid fit in to the general MediaWiki ecosystem? Are Parsoid jobs generated on every edit? If so, why? My understanding is that Parsoid is related to VisualEditor, so I have difficultly understanding how millions of Parsoid jobs would be queued unless they were all related to VisualEditor usage.

> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

What's a bot edit limit?

> Do we have a product for DoS attack detection and -mitigation?

DoS attack? I think it makes sense for all of us to focus on why and how Parsoid is flooding the global job queue. Suggesting anyone was performing a denial-of-service attack is both inappropriate and unhelpful. There are a number of anti-abuse measures built in to MediaWiki, to answer your question generally.",task_subcomment,"(In reply to comment #3)
QUOTE
QUOTE
QUOTE

Where does Parsoid fit in to the general MediaWiki ecosystem? Are Parsoid jobs generated on every edit? If so, why? My understanding is that Parsoid is related to VisualEditor, so I have difficultly understanding how millions of Parsoid jobs would be queued unless they were all related to VisualEditor usage.

QUOTE
QUOTE

What's a bot edit limit?

QUOTE

DoS attack? I think it makes sense for all of us to focus on why and how Parsoid is flooding the global job queue. Suggesting anyone was performing a denial-of-service attack is both inappropriate and unhelpful. There are a number of anti-abuse measures built in to MediaWiki, to answer your question generally.",SOLUTION DISCUSSION
251982,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #2)
> For the record, my null editing respected maxlag. It also started August 28
> and
> ended September 20.

maxlag has actually little relevance as a metric on the task you were doing...",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE

maxlag has actually little relevance as a metric on the task you were doing...",SOLUTION DISCUSSION
251976,Parsoid jobs are not dequeued fast enough during heavy editing activity,"(In reply to comment #3)
> The main issue seems to be MZMcBride's null editing at a rate way beyond even
> bot edit limits.

Can you please clarify how, in your opinion, the null editing retroactively caused a spike a month before its beginning? Thanks.",task_subcomment,"(In reply to comment #3)
QUOTE
QUOTE

Can you please clarify how, in your opinion, the null editing retroactively caused a spike a month before its beginning? Thanks.",SOLUTION DISCUSSION
251971,Parsoid jobs are not dequeued fast enough during heavy editing activity,"We dequeue Parsoid jobs in a throttled manner to avoid overloading the API during edit spikes. This means that abnormal edit rates especially to templates can create a large backlog of jobs in the Parsoid queue. This is then slowly processed over time. Since this is a separate queue this won't hold up other job queues.

The main issue seems to be MZMcBride's null editing at a rate way beyond even bot edit limits. Do we have a product for DoS attack detection and -mitigation?",task_subcomment,"We dequeue Parsoid jobs in a throttled manner to avoid overloading the API during edit spikes. This means that abnormal edit rates especially to templates can create a large backlog of jobs in the Parsoid queue. This is then slowly processed over time. Since this is a separate queue this won't hold up other job queues.

The main issue seems to be MZMcBride's null editing at a rate way beyond even bot edit limits. Do we have a product for DoS attack detection and -mitigation?",INVESTIGATION AND EXPLORATION
251966,Parsoid jobs are not dequeued fast enough during heavy editing activity,"For the record, my null editing respected maxlag. It also started August 28 and ended September 20.

The graph goes wild around July 29, which seems to correspond tightly with ""16:44 logmsgbot: catrope synchronized wmf-config/InitialiseSettings.php 'Enable VE for anons on es/fr/he/it/pl/ru/svwiki; set dewiki back to opt-in mode'"".",task_subcomment,"For the record, my null editing respected maxlag. It also started August 28 and ended September 20.

The graph goes wild around July 29, which seems to correspond tightly with ""16:44 logmsgbot: catrope synchronized wmf-config/InitialiseSettings.php 'Enable VE for anons on es/fr/he/it/pl/ru/svwiki; set dewiki back to opt-in mode'"".",SOLUTION DISCUSSION
251960,Parsoid jobs are not dequeued fast enough during heavy editing activity,"https://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=hume.wikimedia.org&v=823574&m=Global_JobQueue_length&r=hour&z=default&jr=&js=&st=1365625056&z=large

06.11 < TimStarling> mostly parsoid
06.11 < TimStarling> ParsoidCacheUpdateJob: 2413680 queued; 611 claimed (12 active, 599 abandoned)",task_subcomment,"URL

06.11 < TimStarling> mostly parsoid
06.11 < TimStarling> ParsoidCacheUpdateJob: 2413680 queued; 611 claimed (12 active, 599 abandoned)",TASK PROGRESS
56379,"VisualEditor: Right half of toolbar disappears when 
     or 
     appears in image on first line of page","When a page has an image on the first line and the image caption contains a 
     tag or a 
     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, 
     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",task_description,"When a page has an image on the first line and the image caption contains a 
     tag or a 
     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, 
     does not exhibit this problem.

Example from an article: URL

Minimal test case: URL

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",BUG REPRODUCTION
250281,"VisualEditor: Right half of toolbar disappears when 
     or 
     appears in image on first line of page","This was fixed some time ago, I believe; sorry for the very slow triage.",task_subcomment,"This was fixed some time ago, I believe; sorry for the very slow triage.",ACTION ON ISSUE
56377,VisualEditor: Paste validation fails for images in FF,"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",task_description,"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",BUG REPRODUCTION
250158,VisualEditor: Paste validation fails for images in FF,"Change 85213 merged by jenkins-bot:
Ignore all node attributes in clipboard hash

https://gerrit.wikimedia.org/r/85213",task_subcomment,"Change 85213 merged by jenkins-bot:
Ignore all node attributes in clipboard hash

GERRIT_URL",ACTION ON ISSUE
250153,VisualEditor: Paste validation fails for images in FF,"Change 85213 had a related patch set uploaded by Esanders:
Clipboard hash should ignore all node attributes

https://gerrit.wikimedia.org/r/85213",task_subcomment,"Change 85213 had a related patch set uploaded by Esanders:
Clipboard hash should ignore all node attributes

GERRIT_URL",ACTION ON ISSUE
56335,VisualEditor: Surface isn't updated properly for Language annotations,"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",task_description,"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",INVESTIGATION AND EXPLORATION
247687,VisualEditor: Surface isn't updated properly for Language annotations,This was fixed in gerrit 90957.,task_subcomment,This was fixed in gerrit 90957.,SOLUTION USAGE
247684,VisualEditor: Surface isn't updated properly for Language annotations,"The same also happens with Link annotation on MediaWiki.org and on Master.

Since the dataModel seems to change, and the problem *seems* to be in the ce.Surface not changing, I am in dire need of help. 

Based on advice from Roan, I've repeatedly checked the transaction history, and it shows a correct transaction on both meta/language annotation and link/mwInternal and link/mwExternal as it should, based on the annotation actions.

And yet, while the datamodel seems to be updated, the ce.Surface does not.",task_subcomment,"The same also happens with Link annotation on MediaWiki.org and on Master.

Since the dataModel seems to change, and the problem *seems* to be in the ce.Surface not changing, I am in dire need of help. 

Based on advice from Roan, I've repeatedly checked the transaction history, and it shows a correct transaction on both meta/language annotation and link/mwInternal and link/mwExternal as it should, based on the annotation actions.

And yet, while the datamodel seems to be updated, the ce.Surface does not.",BUG REPRODUCTION
56332,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"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]]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",task_description,"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]]s[[Link|.]]
but [[Links]] → [[Linkers]] (this is the expected behaviour for all situations)

See URL

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 URL

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**:
URL",BUG REPRODUCTION
247577,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"Change 86235 merged by jenkins-bot:
Typing into an annotation next to a word break keeps annotation

https://gerrit.wikimedia.org/r/86235",task_subcomment,"Change 86235 merged by jenkins-bot:
Typing into an annotation next to a word break keeps annotation

GERRIT_URL",ACTION ON ISSUE
247571,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"btw, the  is inserted by Parsoid to make sure the document we have (Foo/a>ish?) is translated properly into what the PHP parser understands as by default the PHP parser treats "" + adjecent text"" as a shortcut to extend the lable (e.g. [[book]]s becomes books).",task_subcomment,"btw, the  is inserted by Parsoid to make sure the document we have (Foo/a>ish?) is translated properly into what the PHP parser understands as by default the PHP parser treats "" + adjecent text"" as a shortcut to extend the lable (e.g. [[book]]s becomes books).",SOLUTION DISCUSSION
247567,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"Change 86235 had a related patch set uploaded by Esanders:
Typing into an annotation next to a word break

https://gerrit.wikimedia.org/r/86235",task_subcomment,"Change 86235 had a related patch set uploaded by Esanders:
Typing into an annotation next to a word break

GERRIT_URL",TASK PROGRESS
247563,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"Yeah, this looks like an off-by-one error in the code for link annotations to not span ""word break"" characters.",task_subcomment,"Yeah, this looks like an off-by-one error in the code for link annotations to not span ""word break"" characters.",SOLUTION DISCUSSION
247558,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"You are right, Chris. I just thought VE could easily recognize cases in which punctuation could just be included by mistake, because the wikilink would be something like [[Fun.]], not [[Fun|Fun.]] .",task_subcomment,"You are right, Chris. I just thought VE could easily recognize cases in which punctuation could just be included by mistake, because the wikilink would be something like [[Fun.]], not [[Fun|Fun.]] .",SOLUTION DISCUSSION
247556,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"In some cases the non-alphnumeric is desired - [[Fun.]], [[Westward Ho!]] and [[C++]] are cases that spring immediately to mind.

I think it is best that VE does what you ask it to, whether that is what you wanted or not. Anything typed in the middle of a link should be included in that link in all cases, which would make spotting that trailing punctuation is limited easier.",task_subcomment,"In some cases the non-alphnumeric is desired - [[Fun.]], [[Westward Ho!]] and [[C++]] are cases that spring immediately to mind.

I think it is best that VE does what you ask it to, whether that is what you wanted or not. Anything typed in the middle of a link should be included in that link in all cases, which would make spotting that trailing punctuation is limited easier.",SOLUTION DISCUSSION
247555,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"(I'd add that, at least for me, there is a desired outcome, which is that VE puts the non-alphanumeric character outside the link - of course, I am not sure this is doable or desirable, but this is why I had added my report to 51442.)",task_subcomment,"(I'd add that, at least for me, there is a desired outcome, which is that VE puts the non-alphanumeric character outside the link - of course, I am not sure this is doable or desirable, but this is why I had added my report to 51442.)",SOLUTION USAGE
247552,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,"How to reproduce

1. Load any page in VE
2. Type any sequence of characters ending in one or more non-space characters followed by any non-alphanumeric character except space or underscore. For example: Foo?
3. Link what you have written, including the last character, to any target (e.g. [[Wikipedia]].
4. add any text immediately before the last character. eg. change Foo? to Fooish?
5. Save and look at the diff.

Expected wikitext:
[[Wikipedia|Fooish?]]

Actual wikitext:
[[Wikipedia|Foo]]ish[[Wikipedia|?]]

(In reply to comment #1)
> I think you mean bug 51442

I do. Dyslexia strikes again :(",task_subcomment,"How to reproduce

1. Load any page in VE
2. Type any sequence of characters ending in one or more non-space characters followed by any non-alphanumeric character except space or underscore. For example: Foo?
3. Link what you have written, including the last character, to any target (e.g. [[Wikipedia]].
4. add any text immediately before the last character. eg. change Foo? to Fooish?
5. Save and look at the diff.

Expected wikitext:
[[Wikipedia|Fooish?]]

Actual wikitext:
[[Wikipedia|Foo]]ish[[Wikipedia|?]]

(In reply to comment #1)
QUOTE

I do. Dyslexia strikes again :(",BUG REPRODUCTION
247547,VisualEditor: Inserting into a link with a trailing (linked) non-alphanumeric character causes link pre-annotation to fail,I think you mean bug 51442,task_subcomment,I think you mean bug 51442,BUG REPRODUCTION
56322,VisualEditor: [Regression] Page settings dialog broken in Firefox,"Current VisualEditor-Version:
commit c98a964d5f8495f0d16af9229abbeb0449042d1e
Merge: 3d01a5b e7aed52
Author: jenkins-bot 
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",task_description,"Current VisualEditor-Version:
commit c98a964d5f8495f0d16af9229abbeb0449042d1e
Merge: 3d01a5b e7aed52
Author: jenkins-bot 
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
URL
Line 9

--------------------------
**Version**: unspecified
**Severity**: blocker",BUG REPRODUCTION
247037,VisualEditor: [Regression] Page settings dialog broken in Firefox,Have split the new failure into bug 54928 and am re-closing this one.,task_subcomment,Have split the new failure into bug 54928 and am re-closing this one.,ACTION ON ISSUE
247033,VisualEditor: [Regression] Page settings dialog broken in Firefox,"(In reply to comment #7)
> This should be fixed in https://gerrit.wikimedia.org/r/#/c/85692 , which is
> in
> wmf19 but not in wmf18. enwiki is being upgraded from wmf18 to wmf19 today,
> hopefully that'll fix it.

That's the patch that closed this bug (comment 3). But it appears there is indeed a new bug that causes the page settings dialog to be broken again due to an uncaught exception when the dialog is first created when clicking the page settings button.


It fails in Chrome like this:

Uncaught TypeError: Cannot use 'in' operator to search for 'scrollTop' in undefined load.php?…:102
vendorPropName load.php?…:102
jQuery.extend.css load.php?…:105
Tween.propHooks._default.get load.php?…:136
Tween.cur load.php?…:136
Tween.init load.php?…:135
Tween load.php?…:135
Animation.deferred.promise.createTween load.php?…:131
tweeners.* load.php?…:129
(anonymous function) load.php?…:130
jQuery.extend.each load.php?…:8
createTweens load.php?…:130
Animation load.php?…:132
doAnimation load.php?…:137
jQuery.extend.dequeue load.php?…:25
(anonymous function) load.php?…:26
jQuery.extend.each load.php?…:8
jQuery.fn.jQuery.each load.php?…:4
jQuery.fn.extend.queue load.php?…:26
jQuery.fn.extend.animate load.php?…:138
ve.Element.scrollIntoView load.php?ext.visualEditor…:11
ve.Element.scrollElementIntoView load.php?ext.visualEditor…:12
ve.ui.OptionWidget.setSelected load.php?ext.visualEditor…:404
ve.ui.SelectWidget.selectItem load.php?ext.visualEditor…:400
ve.ui.PagedDialog.addPage load.php?ext.visualEditor…:458
ve.ui.MWMetaDialog.initialize load.php?ext.visualEditor…:461
ve.ui.Window.onFrameInitialize load.php?ext.visualEditor…:353
oo.EventEmitter.emit load.php?ext.visualEditor.bas…:133
ve.ui.Frame.load load.php?ext.visualEditor…:351
ve.ui.WindowSet.open load.php?ext.visualEditor…:356
ve.init.mw.ViewPageTarget.onToolbarMwMetaButtonClick load.php?ext.visualEditor.bas…:87
proxy load.php?…:10
jQuery.event.dispatch load.php?…:45
elemData.handle.eventHandle load.php?…:38",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE

That's the patch that closed this bug (comment 3). But it appears there is indeed a new bug that causes the page settings dialog to be broken again due to an uncaught exception when the dialog is first created when clicking the page settings button.


It fails in Chrome like this:

Uncaught TypeError: Cannot use 'in' operator to search for 'scrollTop' in undefined load.php?…:102
vendorPropName load.php?…:102
jQuery.extend.css load.php?…:105
Tween.propHooks._default.get load.php?…:136
Tween.cur load.php?…:136
Tween.init load.php?…:135
Tween load.php?…:135
Animation.deferred.promise.createTween load.php?…:131
tweeners.* load.php?…:129
(anonymous function) load.php?…:130
jQuery.extend.each load.php?…:8
createTweens load.php?…:130
Animation load.php?…:132
doAnimation load.php?…:137
jQuery.extend.dequeue load.php?…:25
(anonymous function) load.php?…:26
jQuery.extend.each load.php?…:8
jQuery.fn.jQuery.each load.php?…:4
jQuery.fn.extend.queue load.php?…:26
jQuery.fn.extend.animate load.php?…:138
ve.Element.scrollIntoView load.php?ext.visualEditor…:11
ve.Element.scrollElementIntoView load.php?ext.visualEditor…:12
ve.ui.OptionWidget.setSelected load.php?ext.visualEditor…:404
ve.ui.SelectWidget.selectItem load.php?ext.visualEditor…:400
ve.ui.PagedDialog.addPage load.php?ext.visualEditor…:458
ve.ui.MWMetaDialog.initialize load.php?ext.visualEditor…:461
ve.ui.Window.onFrameInitialize load.php?ext.visualEditor…:353
oo.EventEmitter.emit load.php?ext.visualEditor.bas…:133
ve.ui.Frame.load load.php?ext.visualEditor…:351
ve.ui.WindowSet.open load.php?ext.visualEditor…:356
ve.init.mw.ViewPageTarget.onToolbarMwMetaButtonClick load.php?ext.visualEditor.bas…:87
proxy load.php?…:10
jQuery.event.dispatch load.php?…:45
elemData.handle.eventHandle load.php?…:38",BUG REPRODUCTION
247026,VisualEditor: [Regression] Page settings dialog broken in Firefox,"This should be fixed in https://gerrit.wikimedia.org/r/#/c/85692 , which is in wmf19 but not in wmf18. enwiki is being upgraded from wmf18 to wmf19 today, hopefully that'll fix it.",task_subcomment,"This should be fixed in URL , which is in wmf19 but not in wmf18. enwiki is being upgraded from wmf18 to wmf19 today, hopefully that'll fix it.",BUG REPRODUCTION
247020,VisualEditor: [Regression] Page settings dialog broken in Firefox,"Confirmed:

* Working on latest master locally (Chrome).
* Broken on mediawik.org (Chrome).",task_subcomment,"Confirmed:

* Working on latest master locally (Chrome).
* Broken on mediawik.org (Chrome).",BUG REPRODUCTION
247014,VisualEditor: [Regression] Page settings dialog broken in Firefox,"It's still happening, unfortunately. Ed found out it works fine on local and mediawiki.org, though.

TeamGale mentioned this today at en.wp:
<>

Fram tested as well:

<>

I can confirm that the second click just launches an empty window, with only the ""categories"" label text on the left column.

<>",task_subcomment,"It's still happening, unfortunately. Ed found out it works fine on local and mediawiki.org, though.

TeamGale mentioned this today at en.wp:
<>

Fram tested as well:

<>

I can confirm that the second click just launches an empty window, with only the ""categories"" label text on the left column.

<>",BUG REPRODUCTION
247007,VisualEditor: [Regression] Page settings dialog broken in Firefox,"Problem solved. Tested with Firefox 24.0 on Windows 7 64BIT.
>> Page-settings dialog is operational and working.",task_subcomment,"Problem solved. Tested with Firefox 24.0 on Windows 7 64BIT.
QUOTE",SOLUTION USAGE
246999,VisualEditor: [Regression] Page settings dialog broken in Firefox,"Change 85692 merged by jenkins-bot:
ve.Element: Account for getComputerStyle returning null

https://gerrit.wikimedia.org/r/85692",task_subcomment,"Change 85692 merged by jenkins-bot:
ve.Element: Account for getComputerStyle returning null

GERRIT_URL",ACTION ON ISSUE
246990,VisualEditor: [Regression] Page settings dialog broken in Firefox,"Change 85692 had a related patch set uploaded by Krinkle:
ve.Element: Account for getComputerStyle returning null

https://gerrit.wikimedia.org/r/85692",task_subcomment,"Change 85692 had a related patch set uploaded by Krinkle:
ve.Element: Account for getComputerStyle returning null

GERRIT_URL",ACTION ON ISSUE
246981,VisualEditor: [Regression] Page settings dialog broken in Firefox,"I can confirm. When trying to open the Page settings dialog, an exception is thrown for ""style is null"":

ve.Element.js, line:
 		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,

Context:
ve.Element.getBorders = function ( el ) {
	var doc = el.ownerDocument,
		win = doc.parentWindow || doc.defaultView,
		style = win && win.getComputedStyle ?
			win.getComputedStyle( el, null ) : el.currentStyle,
		loc = win && win.getComputedStyle ? true : false,
		$el = $( el ),
		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,",task_subcomment,"I can confirm. When trying to open the Page settings dialog, an exception is thrown for ""style is null"":

ve.Element.js, line:
 		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,

Context:
ve.Element.getBorders = function ( el ) {
	var doc = el.ownerDocument,
		win = doc.parentWindow || doc.defaultView,
		style = win && win.getComputedStyle ?
			win.getComputedStyle( el, null ) : el.currentStyle,
		loc = win && win.getComputedStyle ? true : false,
		$el = $( el ),
		top = parseFloat( loc ? style.borderTopWidth : $el.css( 'borderTopWidth' ) ) || 0,",BUG REPRODUCTION
56314,"VisualEditor: A pawn appears when undoing ""select transclusion and replace with text""","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",task_description,"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",BUG REPRODUCTION
246645,"VisualEditor: A pawn appears when undoing ""select transclusion and replace with text""","This is now fixed, AFAICS. Marking as such.",task_subcomment,"This is now fixed, AFAICS. Marking as such.",SOLUTION USAGE
56271,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"From en.wp.

John Broughton: <>

Andrew Davidson: <>

Salix alba: <>

--------------------------
**Version**: unspecified
**Severity**: enhancement",task_description,"From en.wp.

John Broughton: <>

Andrew Davidson: <>

Salix alba: <>

--------------------------
**Version**: unspecified
**Severity**: enhancement",SOLUTION DISCUSSION
243916,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,I did this in wmf7.,task_subcomment,I did this in wmf7.,TASK PROGRESS
243911,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"FYI, he conversation is now happening at https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Toolbar .",task_subcomment,"FYI, he conversation is now happening at URL .",ACTION ON ISSUE
243905,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"Conversation on the best order of the toolbar is continuing and is pretty thoughtful and indepth at the English VE feedback page. :)

Live link: https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Toolbar_button_priority_proposal

Permanent link to its current state:
https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=573642781#Toolbar_button_priority_proposal",task_subcomment,"Conversation on the best order of the toolbar is continuing and is pretty thoughtful and indepth at the English VE feedback page. :)

Live link: URL

Permanent link to its current state:
URL",FUTURE PLAN
243901,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"My feelings are similar to John's on this.  We can't bury important buttons like references in a dropdown menu.  And, as John points out, for the english user base anyway, the options of underline and strikethrough are very rarely used.  New users are going to experiment with the options most prominently placed, these should be the most useful tools that would lead to a constructive (i.e. not reverted) edit.",task_subcomment,"My feelings are similar to John's on this.  We can't bury important buttons like references in a dropdown menu.  And, as John points out, for the english user base anyway, the options of underline and strikethrough are very rarely used.  New users are going to experiment with the options most prominently placed, these should be the most useful tools that would lead to a constructive (i.e. not reverted) edit.",SOLUTION DISCUSSION
243897,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"Grouping commands under a ""Text format"" drop-down menu is a natural (obvious, intuitive) way to collect commands that are rarely used. For example, bolding of text, in articles, is typically done ONCE (in the lead paragraph, by the author of the article), and then never again. 

A ""Text format"" drop-down menu would take all of the following off of the main toolbar line, leaving space for (at the moment) everything else:

* Bold
* Italic
* Superscript
* Subscript
* Programming language 
* Underline
* Strikethrough
* Clear formatting

Putting all these under a single menu has the advantage of - in the future - allowing projects to control which options are visible in which namespaces. For example, on the English Wikipedia, strikethrough almost certainly should not be a (visible) user choice in mainspace (articlespace), nor should underlining. 

It's important, for SPEED, that frequently used functions are immediately accessible. Articles should have lots of footnotes, a fair number of templates (particularly for footnotes), and at least a couple of images. Putting the related commands into a drop-down menu, as opposed to having them directly on the toolbar, is undesirable: It makes VE less attractive to experienced editors (slower to use) and more difficult for new editors (because now they have to be instructed on, and remember, a TWO-step process (menu, select) rather than a one-step process (click), for important things like images and footnotes.",task_subcomment,"Grouping commands under a ""Text format"" drop-down menu is a natural (obvious, intuitive) way to collect commands that are rarely used. For example, bolding of text, in articles, is typically done ONCE (in the lead paragraph, by the author of the article), and then never again. 

A ""Text format"" drop-down menu would take all of the following off of the main toolbar line, leaving space for (at the moment) everything else:

* Bold
* Italic
* Superscript
* Subscript
* Programming language 
* Underline
* Strikethrough
* Clear formatting

Putting all these under a single menu has the advantage of - in the future - allowing projects to control which options are visible in which namespaces. For example, on the English Wikipedia, strikethrough almost certainly should not be a (visible) user choice in mainspace (articlespace), nor should underlining. 

It's important, for SPEED, that frequently used functions are immediately accessible. Articles should have lots of footnotes, a fair number of templates (particularly for footnotes), and at least a couple of images. Putting the related commands into a drop-down menu, as opposed to having them directly on the toolbar, is undesirable: It makes VE less attractive to experienced editors (slower to use) and more difficult for new editors (because now they have to be instructed on, and remember, a TWO-step process (menu, select) rather than a one-step process (click), for important things like images and footnotes.",SOLUTION DISCUSSION
243891,VisualEditor: Collapse all the text styling buttons (except link?) into a single text-styling icon in the toolbar,"User Pointillist on the English Wikipedia has some really interesting ideas on this subject, posted here: https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=573508478#Toolbar_button_priority_proposal

Without all the very useful images, he writes (please pardon my clumsy textual effort to reproduce his proposal and check out the link to see it the way it should look):

Summary: as discussed above and in bug 54271, the sequence of buttons in the toolbar isn't appropriate for typical article editing activities.

The current toolbar gives too much priority to hard-coded formatting such as Bold, Italic, Lists and Indents. As a result:
* The most important buttons (e.g. for referencing) are pushed into a secondary position and may even be forced onto the ""More"" drop-down
* Wikilinking is incorrectly associated with formatting
* Formatting buttons are divided between the left-end of the toolbar and the ""More"" drop-down
* It isn't immediately clear what ""More"" is offering


I propose that article content buttons should be at the left end and formatting should be at the right end of the toolbar, so something like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * Subscript * Programming language * Unordered list * Ordered list * Reduce indent * Increase indent]

If ""More"" is necessary, it would probably be inserted into the formatting buttons, and the users would expect to find more of them in the drop-down, like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * More]

Of course, this is only a starting point. By the way: underscore and strikeout shouldn't be formatting options in the article space, ""Page title"" isn't necessary as a paragraph style. Thoughts?",task_subcomment,"User Pointillist on the English Wikipedia has some really interesting ideas on this subject, posted here: URL

Without all the very useful images, he writes (please pardon my clumsy textual effort to reproduce his proposal and check out the link to see it the way it should look):

Summary: as discussed above and in bug 54271, the sequence of buttons in the toolbar isn't appropriate for typical article editing activities.

The current toolbar gives too much priority to hard-coded formatting such as Bold, Italic, Lists and Indents. As a result:
* The most important buttons (e.g. for referencing) are pushed into a secondary position and may even be forced onto the ""More"" drop-down
* Wikilinking is incorrectly associated with formatting
* Formatting buttons are divided between the left-end of the toolbar and the ""More"" drop-down
* It isn't immediately clear what ""More"" is offering


I propose that article content buttons should be at the left end and formatting should be at the right end of the toolbar, so something like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * Subscript * Programming language * Unordered list * Ordered list * Reduce indent * Increase indent]

If ""More"" is necessary, it would probably be inserted into the formatting buttons, and the users would expect to find more of them in the drop-down, like this:
[Undo * Redo * Link * Media * Reference * References * Template * Equation * Paragraph * Clear formatting * Bold * Italic * Superscript * More]

Of course, this is only a starting point. By the way: underscore and strikeout shouldn't be formatting options in the article space, ""Page title"" isn't necessary as a paragraph style. Thoughts?",SOLUTION DISCUSSION
56193,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"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`.
",task_description,"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 CODE and CODE.
",BUG REPRODUCTION
812747,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,No events logged in the recursion-guard channel since December 2016.,task_subcomment,No events logged in the recursion-guard channel since December 2016.,ACTION ON ISSUE
619113,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 273586 merged by jenkins-bot:
Fix 'localpage' message handling

[[https://gerrit.wikimedia.org/r/273586]]",task_subcomment,"Change 273586 merged by jenkins-bot:
Fix 'localpage' message handling

[[GERRIT_URL]]",ACTION ON ISSUE
619105,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 273586 had a related patch set uploaded (by Anomie):
Fix 'localpage' message handling

[[https://gerrit.wikimedia.org/r/273586]]
",task_subcomment,"Change 273586 had a related patch set uploaded (by Anomie):
Fix 'localpage' message handling

[[GERRIT_URL]]
",SOLUTION USAGE
619104,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,">>! In T56193#2068539, @Mattflaschen wrote:
> P2680

> 16 0.8985 8361744 Message->isDisabled( ) ../TitleBlacklist.list.php:98

WTF are you doing there, TitleBlacklist?",task_subcomment,"QUOTE
QUOTE

QUOTE

WTF are you doing there, TitleBlacklist?",SOCIAL CONVERSATION
618954,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,P2680,task_subcomment,P2680,TASK PROGRESS
618953,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,Got this locally on MediaWiki-Vagrant.,task_subcomment,Got this locally on MediaWiki-Vagrant.,BUG REPRODUCTION
588673,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,">>! In T56193#1926036, @mmodell wrote:
> @bd808: do you think there is any value in keeping this error message?  It seems to me like it's expected behavior at this point and not really valuable.

Disabling the log message has been proposed as a patch before () and @TStarling at that time wanted the message to stay until the underlying bug was fixed.",task_subcomment,"QUOTE
QUOTE

Disabling the log message has been proposed as a patch before (>! In T56193#1603723, @Southparkfan wrote:
> Seems to not be Wikimedia-only, I experience this error too:

This looks to be a variant on one of the patterns noted in T56193#554201:
* getLanguage() → Log in from cookies → User::isUsableName() → Message → getLanguage()

In this particular case, the `wfMessage()` call is going to be rendered using the `inContentLanguage()` method but before it can get that far the Parser wants to know the User's language.

The statement of ""It should be a pretty simple change for Brad or Chris."" in T56193#554221 has thus far proved to be a variant on [[https://en.wikipedia.org/wiki/Fermat's_Last_Theorem|Fermat's Last Theorem]]. Many people have looked for the proof but none have yet been able to provide one.",task_subcomment,"QUOTE
QUOTE

This looks to be a variant on one of the patterns noted in T56193#554201:
* getLanguage() → Log in from cookies → User::isUsableName() → Message → getLanguage()

In this particular case, the CODE call is going to be rendered using the CODE method but before it can get that far the Parser wants to know the User's language.

The statement of ""It should be a pretty simple change for Brad or Chris."" in T56193#554221 has thus far proved to be a variant on [[URL Last Theorem]]. Many people have looked for the proof but none have yet been able to provide one.",INVESTIGATION AND EXPLORATION
520523,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Seems to not be Wikimedia-only, I experience this error too:
| Product | version
| MediaWiki | 1.25.2 (9c89a16) 18:08, 3 September 2015
| HHVM | 3.8.1 (srv)
| MariaDB | 10.0.20-MariaDB-0+deb8u1-log
Configuration: https://github.com/miraheze/mw-config/blob/master/LocalSettings.php
```
#0 /srv/mediawiki/w/includes/StubObject.php(204): RequestContext->getLanguage()
#1 /srv/mediawiki/w/includes/StubObject.php(160): StubUserLang->_newObject()
#2 /srv/mediawiki/w/includes/parser/ParserOptions.php(588): StubObject->_unstub()
#3 /srv/mediawiki/w/includes/cache/MessageCache.php(148): ParserOptions->__construct()
#4 /srv/mediawiki/w/includes/cache/MessageCache.php(988): MessageCache->getParserOptions()
#5 /srv/mediawiki/w/includes/Message.php(1059): MessageCache->transform()
#6 /srv/mediawiki/w/includes/Message.php(726): Message->transformText()
#7 /srv/mediawiki/w/includes/Message.php(789): Message->toString()
#8 /srv/mediawiki/w/includes/User.php(748): Message->text()
#9 /srv/mediawiki/w/includes/User.php(790): User::isUsableName()
#10 /srv/mediawiki/w/extensions/CentralAuth/includes/CentralAuthHooks.php(1082): User::isCreatableName()
#11 /srv/mediawiki/w/extensions/CentralAuth/includes/CentralAuthHooks.php(835): CentralAuthHooks::attemptAddUser()
#12 /srv/mediawiki/w/includes/Hooks.php(209): CentralAuthHooks::onUserLoadFromSession()
#13 /srv/mediawiki/w/includes/User.php(1132): Hooks::run()
#14 /srv/mediawiki/w/includes/User.php(361): User->loadFromSession()
#15 /srv/mediawiki/w/includes/User.php(4942): User->load()
#16 /srv/mediawiki/w/includes/User.php(2587): User->loadOptions()
#17 /srv/mediawiki/w/includes/context/RequestContext.php(342): User->getOption()
#18 /srv/mediawiki/w/includes/Message.php(577): RequestContext->getLanguage()
#19 /srv/mediawiki/w/includes/context/RequestContext.php(436): Message->setContext()
#20 /srv/mediawiki/w/includes/context/ContextSource.php(176): RequestContext->msg()
#21 /srv/mediawiki/w/includes/OutputPage.php(974): ContextSource->msg()
#22 /srv/mediawiki/w/includes/page/Article.php(512): OutputPage->setPageTitle()
#23 /srv/mediawiki/w/includes/actions/ViewAction.php(44): Article->view()
#24 /srv/mediawiki/w/includes/MediaWiki.php(395): ViewAction->show()
#25 /srv/mediawiki/w/includes/MediaWiki.php(273): MediaWiki->performAction()
#26 /srv/mediawiki/w/includes/MediaWiki.php(566): MediaWiki->performRequest()
#27 /srv/mediawiki/w/includes/MediaWiki.php(414): MediaWiki->main()
#28 /srv/mediawiki/w/index.php(41): MediaWiki->run()
#29 {main}
```",task_subcomment,"Seems to not be Wikimedia-only, I experience this error too:
| Product | version
| MediaWiki | 1.25.2 (9c89a16) 18:08, 3 September 2015
| HHVM | 3.8.1 (srv)
| MariaDB | 10.0.20-MariaDB-0+deb8u1-log
Configuration: URL
``CODE``",SOLUTION USAGE
466726,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"That is still hitting us, stracktraces can be found in logstash with _type: mediawiki and channel: recursion-guard.

Is anyone working on it?",task_subcomment,"That is still hitting us, stracktraces can be found in logstash with _type: mediawiki and channel: recursion-guard.

Is anyone working on it?",BUG REPRODUCTION
400813,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 174057 abandoned by Umherirrender:
Avoid calling Title::makeTitleSafe in User::idFromName

Reason:
Old branch, proper fix already in master (Ib902573996c69d1e77527cc7b2faf4e7fa5d3daf)

[[https://gerrit.wikimedia.org/r/174057]]",task_subcomment,"Change 174057 abandoned by Umherirrender:
Avoid calling Title::makeTitleSafe in User::idFromName

Reason:
Old branch, proper fix already in master (Ib902573996c69d1e77527cc7b2faf4e7fa5d3daf)

[[GERRIT_URL]]",ACTION ON ISSUE
239724,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 174057 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174057",task_subcomment,"Change 174057 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

GERRIT_URL",ACTION ON ISSUE
239717,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 174051 merged by jenkins-bot:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051",task_subcomment,"Change 174051 merged by jenkins-bot:
Avoid calling Title::makeTitleSafe in User::idFromName

GERRIT_URL",TASK PROGRESS
239711,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 174051 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

https://gerrit.wikimedia.org/r/174051",task_subcomment,"Change 174051 had a related patch set uploaded by Ori.livneh:
Avoid calling Title::makeTitleSafe in User::idFromName

GERRIT_URL",ACTION ON ISSUE
239703,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"(In reply to Tim Starling from comment #17)
> Looks like bug 41201 again (""UserLoadFromSession considered evil""). I
> probably should have pushed that one a bit harder during the CA2 sprint. It
> should be a pretty simple change for Brad or Chris.

Is it?",task_subcomment,"(In reply to Tim Starling from comment #17)
QUOTE
QUOTE
QUOTE

Is it?",ACTION ON ISSUE
239699,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Looks like bug 41201 again (""UserLoadFromSession considered evil""). I probably should have pushed that one a bit harder during the CA2 sprint. It should be a pretty simple change for Brad or Chris.",task_subcomment,"Looks like bug 41201 again (""UserLoadFromSession considered evil""). I probably should have pushed that one a bit harder during the CA2 sprint. It should be a pretty simple change for Brad or Chris.",BUG REPRODUCTION
239696,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,Hiding the warning in fatal monitor with Gerrit change #102557 - the stacktrace logging is still on,task_subcomment,Hiding the warning in fatal monitor with Gerrit change #102557 - the stacktrace logging is still on,SOLUTION DISCUSSION
239695,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"So the problem generally appears to be that Language::getLanguage() unstubs the User object by trying to fetch the 'language' pref, and the various hooks called during that process may themselves wind up doing something that tries to call Language::getLanguage(). There are also some instances where something hooking 'UserGetLanguageObject' tries to call getLanguage().

Code paths I see in a quick look through the log include:
* getLanguage() → Log in from cookies → Trying to get the localized alias for NS_USER on wikis with variants → getLanguage()
** This seems to be a large number of the instances: srwiki, uzwiktionary, kuwiktionary, etc.
* getLanguage() → Autocreate account → AbuseFilter's checkNewAccount hook → dividebyzero → Trying to get localized error message → getLanguage()
** enwiki and eswiki have this
* getLanguage() → ULS's getLanguage hook → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → TitleBlacklist hit → Trying to get localized error message → getLanguage()
* getLanguage() → Autocreate account → NewUserMessage::createNewUserMessage → various different code paths involving the parser and/or MessageCache → getLanguage()

I think that the fallback behavior added in Gerrit change 48080 is probably the best thing to do in general.

BTW, the previous bug on this topic was probably bug 44754.",task_subcomment,"So the problem generally appears to be that Language::getLanguage() unstubs the User object by trying to fetch the 'language' pref, and the various hooks called during that process may themselves wind up doing something that tries to call Language::getLanguage(). There are also some instances where something hooking 'UserGetLanguageObject' tries to call getLanguage().

Code paths I see in a quick look through the log include:
* getLanguage() → Log in from cookies → Trying to get the localized alias for NS_USER on wikis with variants → getLanguage()
** This seems to be a large number of the instances: srwiki, uzwiktionary, kuwiktionary, etc.
* getLanguage() → Autocreate account → AbuseFilter's checkNewAccount hook → dividebyzero → Trying to get localized error message → getLanguage()
** enwiki and eswiki have this
* getLanguage() → ULS's getLanguage hook → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → User::saveOptions → BetaFeatures's hook on UserSaveOptions → VisualEditor's onGetBetaPreferences hook or VectorBeta's prefs hook → getLanguage()
* getLanguage() → Autocreate account → TitleBlacklist hit → Trying to get localized error message → getLanguage()
* getLanguage() → Autocreate account → NewUserMessage::createNewUserMessage → various different code paths involving the parser and/or MessageCache → getLanguage()

I think that the fallback behavior added in Gerrit change 48080 is probably the best thing to do in general.

BTW, the previous bug on this topic was probably bug 44754.",INVESTIGATION AND EXPLORATION
239693,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"(In reply to comment #12)
> What a scary backtrace. It seems to relate on automatic creation of local
> accounts interacting with abuse filter. No wonder it seems to only happen in
> production.
> 
> I have no idea how to fix this. Perhaps automatic local account creation
> should
> happen somewhere else?

cc Anomie",task_subcomment,"(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

cc Anomie",ACTION ON ISSUE
239692,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Given the backtrace, this does not seem to be an i18n issue, except for that the class (Stub)Language is involved at one level. Reclassifying and updating CCs accordingly. Niklas and I will stay on CC.",task_subcomment,"Given the backtrace, this does not seem to be an i18n issue, except for that the class (Stub)Language is involved at one level. Reclassifying and updating CCs accordingly. Niklas and I will stay on CC.",ACTION ON ISSUE
239688,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"What a scary backtrace. It seems to relate on automatic creation of local accounts interacting with abuse filter. No wonder it seems to only happen in production.

I have no idea how to fix this. Perhaps automatic local account creation should happen somewhere else?",task_subcomment,"What a scary backtrace. It seems to relate on automatic creation of local accounts interacting with abuse filter. No wonder it seems to only happen in production.

I have no idea how to fix this. Perhaps automatic local account creation should happen somewhere else?",INVESTIGATION AND EXPLORATION
239686,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"(In reply to comment #6)
> Would it be possible to provide more information about which wiki(s) display
> this behavior, or possibly even page(s)? Being able t reproduce this would
> probably go a long way towards resolving it.

I added a trace; additional ones are available in fluorine:/a/mw-log/recursion-guard-stack-trace.log. If you want me to grab additional ones, let me know.

(In reply to comment #7)
> Side note: the logs this information is extracted from, could we make those
> more widely available so they could get more eyeballs? From my experience
> doing this at translatewiki.net it often helps in identifying issues a lot
> earlier.

Yeah, fair point. We (platform & ops) are working on setting up a better platform for log analysis, probably using logstash. The current situation sucks.",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE
QUOTE

I added a trace; additional ones are available in fluorine:/a/mw-log/recursion-guard-stack-trace.log. If you want me to grab additional ones, let me know.

(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE

Yeah, fair point. We (platform & ops) are working on setting up a better platform for log analysis, probably using logstash. The current situation sucks.",SOLUTION DISCUSSION
239684,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Created attachment 13858
stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log

**Attached**: {F11344}",task_subcomment,"Created attachment 13858
stack trace from fluorine:/a/mw-log/recursion-guard-stack-trace.log

**Attached**: {F11344}",BUG REPRODUCTION
239681,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 96709 merged by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709",task_subcomment,"Change 96709 merged by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

GERRIT_URL",ACTION ON ISSUE
239677,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Change 96709 had a related patch set uploaded by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

https://gerrit.wikimedia.org/r/96709",task_subcomment,"Change 96709 had a related patch set uploaded by Ori.livneh:
Enable recursion-guard log bucket to investigate bug 54193

GERRIT_URL",ACTION ON ISSUE
239671,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Side note: the logs this information is extracted from, could we make those more widely available so they could get more eyeballs? From my experience doing this at translatewiki.net it often helps in identifying issues a lot earlier.",task_subcomment,"Side note: the logs this information is extracted from, could we make those more widely available so they could get more eyeballs? From my experience doing this at translatewiki.net it often helps in identifying issues a lot earlier.",SOLUTION DISCUSSION
239663,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Would it be possible to provide more information about which wiki(s) display this behavior, or possibly even page(s)?

Being able t reproduce this would probably go a long way towards resolving it.",task_subcomment,"Would it be possible to provide more information about which wiki(s) display this behavior, or possibly even page(s)?

Being able t reproduce this would probably go a long way towards resolving it.",BUG REPRODUCTION
239655,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,>200 of these every hour in /a/mw-log/apache2.log,task_subcomment,QUOTE,ACTION ON ISSUE
239649,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Every 2.0s: tail -n 1000 /home/wikipedia/syslog/apache.log | grep -v 'Search backend error' | grep -v -i 'swift' | grep 'PHP\|Segmentation ...  Tue Nov 12 22:33:46 2013

    240 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf3/includes/context/RequestContext.php on line 284
     72 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf2/includes/context/RequestContext.php on line 284",task_subcomment,"Every 2.0s: tail -n 1000 /home/wikipedia/syslog/apache.log | grep -v 'Search backend error' | grep -v -i 'swift' | grep 'PHP\|Segmentation ...  Tue Nov 12 22:33:46 2013

    240 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf3/includes/context/RequestContext.php on line 284
     72 Warning:  Recursion detected in RequestContext::getLanguage in /usr/local/apache/common-local/php-1.23wmf2/includes/context/RequestContext.php on line 284",BUG REPRODUCTION
239645,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Yup, there are these warnings almost always shown in the last 1000 lines of the apache syslogs",task_subcomment,"Yup, there are these warnings almost always shown in the last 1000 lines of the apache syslogs",MOTIVATION
239640,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,"Sam, are these still being observed, or have they gone away?",task_subcomment,"Sam, are these still being observed, or have they gone away?",BUG REPRODUCTION
239635,Warning:  Recursion detected in RequestContext::getLanguage in /includes/context/RequestContext.php on line 284,I can't do anything about this without a backtrace. Not sure how to mark that.,task_subcomment,I can't do anything about this without a backtrace. Not sure how to mark that.,ACTION ON ISSUE
56140,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","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  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}",task_description,"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  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}",SOLUTION DISCUSSION
2132794,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",">>! In T56140#8877796, @Jdforrester-WMF wrote:
> For the transition, certainly. Long-term, probably not, and hacks to generate the transclusion data would have to make way for proper documentation.
Having shared TemplateData between pages or generating TemplateData programmatically, which those cases cover, are legitimate uses of TemplateData and not hacks. If anything, more templates with the same parameter configurations (like, for example, navigation templates) would benefit from it if it was more widely adopted. Currently, TemplateData adoption is too low, and if anything, we should look for ways to encourage TemplateData adoption, not to discourage it.",task_subcomment,"QUOTE
QUOTE
Having shared TemplateData between pages or generating TemplateData programmatically, which those cases cover, are legitimate uses of TemplateData and not hacks. If anything, more templates with the same parameter configurations (like, for example, navigation templates) would benefit from it if it was more widely adopted. Currently, TemplateData adoption is too low, and if anything, we should look for ways to encourage TemplateData adoption, not to discourage it.",SOLUTION DISCUSSION
2132790,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","For the record, TemplateData is also read to create automatic template examples, see https://ru.wikipedia.org/wiki/Module:TemplateDataDoc
This is not a use case that will be supported by Lua if TemplateData data gets moved to another slot, without implementing {T107119}",task_subcomment,"For the record, TemplateData is also read to create automatic template examples, see URL
This is not a use case that will be supported by Lua if TemplateData data gets moved to another slot, without implementing {T107119}",SOLUTION USAGE
2131469,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",">>! In T56140#8877796, @Jdforrester-WMF wrote:
> Long-term, probably not, and hacks to generate the transclusion data would have to make way for proper documentation.

These are not hacks, these are proper solutions using the public API of TemplateData (a JSON blob), making template editors’ lives easier. How can this “proper documentation” be created without duplicating everything between the TemplateData-compatible documentation and the actually useful documentation (i.e. one that contains e.g. inline links)? Looking at the PoC patch, keeping support for JSON blobs in wikitext would probably need 5-10 lines of extra code, which doesn’t sound like a horrible tech debt even long-term.

MediaWiki developers seem to sometimes forget how much the community relies on templates. Parsoid doesn’t support templates emitting unbalanced wikitext. The result? Large blocks of text, sometimes even whole pages, that have to be edited in wikitext in VisualEditor, or can’t be edited at all. Structured Data on Commons doesn’t support templates at all. The result? Instead of either using or replacing wikitext, all machine-readable metadata is still present in wikitext in one form, and bots duplicate it to another form, making actual edits to pages. Please don’t do the same mistake again and again.",task_subcomment,"QUOTE
QUOTE

These are not hacks, these are proper solutions using the public API of TemplateData (a JSON blob), making template editors’ lives easier. How can this “proper documentation” be created without duplicating everything between the TemplateData-compatible documentation and the actually useful documentation (i.e. one that contains e.g. inline links)? Looking at the PoC patch, keeping support for JSON blobs in wikitext would probably need 5-10 lines of extra code, which doesn’t sound like a horrible tech debt even long-term.

MediaWiki developers seem to sometimes forget how much the community relies on templates. Parsoid doesn’t support templates emitting unbalanced wikitext. The result? Large blocks of text, sometimes even whole pages, that have to be edited in wikitext in VisualEditor, or can’t be edited at all. Structured Data on Commons doesn’t support templates at all. The result? Instead of either using or replacing wikitext, all machine-readable metadata is still present in wikitext in one form, and bots duplicate it to another form, making actual edits to pages. Please don’t do the same mistake again and again.",SOLUTION DISCUSSION
2131467,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","Many many templates are not documented by an individual JSON for each single template, but derived from series of JSON data generated by documentation template or Lua module, creating TemplateData for many productive templates.

German Wikipedia is documenting latin based language templates by [[ https://de.wikipedia.org/wiki/Template:lang/Latn/Doku | Template:lang/Latn/Doku ]] which provides one unique pattern for all of them ([[ https://de.wikipedia.org/w/index.php?search=hastemplate%3A%22Lang%2FLatn%2FDoku%22&title=Spezial%3ASuche&profile=advanced&fulltext=1&ns10=1 | 196 single templates ]]). The TemplateData and the entire documentation page is produced by very short transclusions like ##{{lang/Latn/Doku|CODE=lv|SPRACHE=lettischer Sprache|EXAMPLE=Rīga}}## in [[ https://de.wikipedia.org/w/index.php?title=Template:lvS&action=edit | Template:lvS ]].
[[ https://de.wikipedia.org/wiki/Category:Vorlage:Metadokumentation | Category:Vorlage:Metadokumentation ]] lists a pile (53) of such meta documentation patterns. Currently we are planning schemes which are generating full documentation pages for several 10,000 single productive templates, with heading TemplateData of course.

The concept of independent namespace for TemplateData is based on the assumption that every productive template has one static individual JSON code without any JSON code injection.",task_subcomment,"Many many templates are not documented by an individual JSON for each single template, but derived from series of JSON data generated by documentation template or Lua module, creating TemplateData for many productive templates.

German Wikipedia is documenting latin based language templates by [[ URL | Template:lang/Latn/Doku ]] which provides one unique pattern for all of them ([[ URL | 196 single templates ]]). The TemplateData and the entire documentation page is produced by very short transclusions like ##{{lang/Latn/Doku|CODE=lv|SPRACHE=lettischer Sprache|EXAMPLE=Rīga}}## in [[ URL | Template:lvS ]].
[[ URL | Category:Vorlage:Metadokumentation ]] lists a pile (53) of such meta documentation patterns. Currently we are planning schemes which are generating full documentation pages for several 10,000 single productive templates, with heading TemplateData of course.

The concept of independent namespace for TemplateData is based on the assumption that every productive template has one static individual JSON code without any JSON code injection.",SOLUTION DISCUSSION
2129667,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",">>! In T56140#8869098, @Tacsipacsi wrote:
> Would the current JSON structure continue to be supported?

For the transition, certainly. Long-term, probably not, and hacks to generate the transclusion data would have to make way for proper documentation.

> [[https://commons.wikimedia.org/wiki/Template:TemplateBox|c:Template:TemplateBox]] relies on being able to generate JSON to avoid unnecessarily duplicating content between the TemplateData and the wikitext description (the latter supports wiki markup, so TemplateData can’t entirely supersede it, unless TemplateData will also start to support wiki markup).

Ack, the very-intentional lack of support for wikitext (and all the horrors that entails) means some forms of documentation are hard to do. We should probably add additional fields including link targets and good- and bad-example samples to augment the structured data so that it works better for secondary use cases. That's outside the scope of this task, however.",task_subcomment,"QUOTE
QUOTE

For the transition, certainly. Long-term, probably not, and hacks to generate the transclusion data would have to make way for proper documentation.

QUOTE

Ack, the very-intentional lack of support for wikitext (and all the horrors that entails) means some forms of documentation are hard to do. We should probably add additional fields including link targets and good- and bad-example samples to augment the structured data so that it works better for secondary use cases. That's outside the scope of this task, however.",SOLUTION DISCUSSION
2127607,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","Change 921693 had a related patch set uploaded (by TK-999; author: TK-999):
%%%[mediawiki/extensions/TemplateData@master] [PoC] MCR slot for TemplateData content%%%
https://gerrit.wikimedia.org/r/921693",task_subcomment,"Change 921693 had a related patch set uploaded (by TK-999; author: TK-999):
%%%[mediawiki/extensions/TemplateData@master] [PoC] MCR slot for TemplateData content%%%
GERRIT_URL",ACTION ON ISSUE
2127581,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","Would the current JSON structure continue to be supported? [[https://commons.wikimedia.org/wiki/Template:TemplateBox|c:Template:TemplateBox]] relies on being able to generate JSON to avoid unnecessarily duplicating content between the TemplateData and the wikitext description (the latter supports wiki markup, so TemplateData can’t entirely supersede it, unless TemplateData will also start to support wiki markup).",task_subcomment,"Would the current JSON structure continue to be supported? [[URL relies on being able to generate JSON to avoid unnecessarily duplicating content between the TemplateData and the wikitext description (the latter supports wiki markup, so TemplateData can’t entirely supersede it, unless TemplateData will also start to support wiki markup).",SOLUTION USAGE
2127544,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",Tagging #Wikimedia-Hackathon-2023 to showcase a basic PoC created during this event.,task_subcomment,Tagging #Wikimedia-Hackathon-2023 to showcase a basic PoC created during this event.,POTENTIAL NEW ISSUES AND REQUESTS
1200143,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","See related approach by [[ https://www.mediawiki.org/wiki/Module:TNT | Module:TNT ]] -- it stores templatedata [[ https://commons.wikimedia.org/wiki/Data:Templatedata/Graph:Lines.tab | as a table (example) ]]. In this case  will be dynamically generated during the parse time, and is available to every language/every wiki.",task_subcomment,"See related approach by [[ URL | Module:TNT ]] -- it stores templatedata [[ URL | as a table (example) ]]. In this case  will be dynamically generated during the parse time, and is available to every language/every wiki.", SOLUTION DISCUSSION 
1199675,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","Please note that these are not static pages.
* The URI comment looks like assigning a static page which is simply transcluded.
* Entire JSON TemplateData descriptions are generated individually by template or Lua programming; depending on parameters and existence of other pages.
* You may have a look e.g. at [[ https://de.wikipedia.org/w/index.php?title=Vorlage:enS&action=edit | use of lang/Latn/Doku ]] and the derived page.",task_subcomment,"Please note that these are not static pages.
* The URI comment looks like assigning a static page which is simply transcluded.
* Entire JSON TemplateData descriptions are generated individually by template or Lua programming; depending on parameters and existence of other pages.
* You may have a look e.g. at [[ URL | use of lang/Latn/Doku ]] and the derived page.",SOLUTION USAGE
1199609,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",">>! In T56140#3143510, @PerfektesChaos wrote:
> * There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
> ** See [[https://de.wikipedia.org/wiki/Kategorie:Vorlage:Metadokumentation | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sometimes parameters.

Interesting. json-schema allows referencing/embedding other schemas by using a special `""$ref"": ""[URI to another schema]""` key. Maybe something like that could be implemented in TemplateData instead of requiring the use of parser functions.

",task_subcomment,"QUOTE
QUOTE
QUOTE

Interesting. json-schema allows referencing/embedding other schemas by using a special CODE key. Maybe something like that could be implemented in TemplateData instead of requiring the use of parser functions.

",SOLUTION DISCUSSION
911940,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",This could be held like doc subpages or currently deployed css subpages instead,task_subcomment,This could be held like doc subpages or currently deployed css subpages instead,SOLUTION DISCUSSION
1068644,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","I do raise two issues against the proposal, at least for mandatory evaluation of JSON pages only.
* Pro #2 reads as: “Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages”
** This goes for any kind of lengthy documentation, and is usually solved by transclusion of a separated ##/doc## into main template page.
** German Wikipedia is using that technique for any longer template documentation since 2008, and enforces TemplateData on separated docpage for all productive templates.
* There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
** See [[https://de.wikipedia.org/wiki/Kategorie:Vorlage:Metadokumentation | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sometimes parameters.
Optional separated ##.json## subpages may be introduced, but classic #### approach needs to be supported, too.
",task_subcomment,"I do raise two issues against the proposal, at least for mandatory evaluation of JSON pages only.
* Pro #2 reads as: “Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages”
** This goes for any kind of lengthy documentation, and is usually solved by transclusion of a separated ##/doc## into main template page.
** German Wikipedia is using that technique for any longer template documentation since 2008, and enforces TemplateData on separated docpage for all productive templates.
* There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
** See [[URL | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sometimes parameters.
Optional separated ##.json## subpages may be introduced, but classic #### approach needs to be supported, too.
",SOLUTION DISCUSSION
834499,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","I do raise two issues against the proposal, at least for mandatory evaluation of JSON pages only.
* Pro #2 reads as: “Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages”
** This goes for any kind of lengthy documentation, and is usually solved by transclusion of a separated ##/doc## into main template page.
** German Wikipedia is using that technique for any longer template documentation since 2008, and enforces TemplateData on separated docpage for all productive templates.
* There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
** See [[https://de.wikipedia.org/wiki/Kategorie:Vorlage:Metadokumentation | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sommetimes parameters.
Optional separated ##.json## subpages may be introduced, but classic #### approach needs to be supported, too.
",task_subcomment,"I do raise two issues against the proposal, at least for mandatory evaluation of JSON pages only.
* Pro #2 reads as: “Document templates without needing to make edits to templates that are potentially transcluded across large swaths of pages”
** This goes for any kind of lengthy documentation, and is usually solved by transclusion of a separated ##/doc## into main template page.
** German Wikipedia is using that technique for any longer template documentation since 2008, and enforces TemplateData on separated docpage for all productive templates.
* There are JSON objects built by template-like transclusion via ##{{#tag:}}## syntax.
** See [[URL | Kategorie:Vorlage:Metadokumentation]] on German Wikipedia – a dozen of so-called “meta documentation” pattern pages is generating nearly thousand TemplateData objects on particular template pages, controlled by template name and sommetimes parameters.
Optional separated ##.json## subpages may be introduced, but classic #### approach needs to be supported, too.
",SOLUTION DISCUSSION
590984,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","I've fiddled with this because either {T487} or {T107595} would both meet this need. I think the latter is both more likely to occur and a better outcome, but…",task_subcomment,"I've fiddled with this because either {T487} or {T107595} would both meet this need. I think the latter is both more likely to occur and a better outcome, but…",SOLUTION DISCUSSION
236209,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",Re-wording; this is blocked by https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces being implemented.,task_subcomment,Re-wording; this is blocked by URL being implemented.,SOLUTION DISCUSSION
236205,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","See also:
https://www.mediawiki.org/wiki/Requests_for_comment/Associated_namespaces#Use_case_2b:_Structured_template_documentation",task_subcomment,"See also:
URL",SOLUTION USAGE
236200,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot","I talked about that briefly on IRC, we decided that since this is specifically about the namespace proposal, until we decided what to do about it, we'd leave both open. And closing that bug may not necessarily close this bug.",task_subcomment,"I talked about that briefly on IRC, we decided that since this is specifically about the namespace proposal, until we decided what to do about it, we'd leave both open. And closing that bug may not necessarily close this bug.",SOLUTION DISCUSSION
236195,"Move TemplateData to its own JSON-content namespace and associate with Template-namespace, or to its own TemplateData content model and revision slot",Is this a dupe of https://bugzilla.wikimedia.org/show_bug.cgi?id=50512#c0 ?,task_subcomment,Is this a dupe of URL ?,BUG REPRODUCTION
56045,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"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
Error generating thumbnail


    Error generating thumbnail
    

    
Error creating thumbnail:

    





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 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",task_description,"When requesting random images from Commons' MediaWiki API and requesting a thumbnail for it, I often get a HTTP 500.

For example:



GET URL
HTTP 500
Error generating thumbnail


    Error generating thumbnail
    

    
Error creating thumbnail:

    





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 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",BUG REPRODUCTION
254806,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"[02:06:08]  Can someone depool mw1154 from the image scaler cluster?
[02:06:20]  what's wrong with it?
[02:07:40]  It's seemingly generating a lot more errors (by a factor of 2 or so) than any of the other scalers
[02:07:41]  https://bugzilla.wikimedia.org/show_bug.cgi?id=54045
[02:08:32]  root@mw1154:~# ls /sys/fs/cgroup/memory/mediawiki/job
[02:08:33]  ls: cannot access /sys/fs/cgroup/memory/mediawiki/job: No such file or directory
[02:08:35]  blergh
[02:09:01]  fixed
[02:09:58]  is that's what's up with it?
[02:10:05]  yes, fixed
[02:10:09]  awesome
[02:10:10]  thanks",task_subcomment,"[02:06:08]  Can someone depool mw1154 from the image scaler cluster?
[02:06:20]  what's wrong with it?
[02:07:40]  It's seemingly generating a lot more errors (by a factor of 2 or so) than any of the other scalers
[02:07:41]  URL
[02:08:32]  root@mw1154:~# ls /sys/fs/cgroup/memory/mediawiki/job
[02:08:33]  ls: cannot access /sys/fs/cgroup/memory/mediawiki/job: No such file or directory
[02:08:35]  blergh
[02:09:01]  fixed
[02:09:58]  is that's what's up with it?
[02:10:05]  yes, fixed
[02:10:09]  awesome
[02:10:10]  thanks",TASK PROGRESS
254803,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"Yup, still mw1154


reedy@fluorine:/a/mw-log$ grep -c mw1153 thumbnail.log
50057
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
125850
reedy@fluorine:/a/mw-log$ grep -c mw1155 thumbnail.log
50451
reedy@fluorine:/a/mw-log$ grep -c mw1156 thumbnail.log
50584
reedy@fluorine:/a/mw-log$ grep -c mw1157 thumbnail.log
51015
reedy@fluorine:/a/mw-log$ grep -c mw1158 thumbnail.log
50386
reedy@fluorine:/a/mw-log$ grep -c mw1159 thumbnail.log
50134
reedy@fluorine:/a/mw-log$ grep -c mw1160 thumbnail.log
51486",task_subcomment,"Yup, still mw1154


reedy@fluorine:/a/mw-log$ grep -c mw1153 thumbnail.log
50057
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
125850
reedy@fluorine:/a/mw-log$ grep -c mw1155 thumbnail.log
50451
reedy@fluorine:/a/mw-log$ grep -c mw1156 thumbnail.log
50584
reedy@fluorine:/a/mw-log$ grep -c mw1157 thumbnail.log
51015
reedy@fluorine:/a/mw-log$ grep -c mw1158 thumbnail.log
50386
reedy@fluorine:/a/mw-log$ grep -c mw1159 thumbnail.log
50134
reedy@fluorine:/a/mw-log$ grep -c mw1160 thumbnail.log
51486",BUG REPRODUCTION
254800,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,Ganglia graphs suggest so (mw1154 has less activity) but I haven't specificly tested.,task_subcomment,Ganglia graphs suggest so (mw1154 has less activity) but I haven't specificly tested.,INVESTIGATION AND EXPLORATION
254797,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,Part of the question would be is it still the same machine? (based on the fact it's already changed once),task_subcomment,Part of the question would be is it still the same machine? (based on the fact it's already changed once),TASK PROGRESS
254793,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,Could this server be taken out of rotation until the issue is resolved?,task_subcomment,Could this server be taken out of rotation until the issue is resolved?,ACTION ON ISSUE
254787,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"The entries in /a/mw-log/thumbnail.log are often hard to correlate since they use temporary file names. However it appears some (or all?) contain a MediaWiki File-namespace url as well.

I just got another HTTP 500 Internal Server Error and found the following entry:

URL: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e8/Trevor_Parscal_December_2008.jpg/660px-Trevor_Parscal_December_2008.jpg

Triggered from an  tag on https://commons.wikimedia.org/w/index.php?title=File:Trevor_Parscal_December_2008.jpg&action=submit when previewing an edit.


[04:11 UTC] krinkle at fluorine in /a/mw-log
$ tail thumbnail.log  -n500 | ack-grep Trevor -C 10

Bytes: 0xFF 0x27 0x20 0x69"" from ""'/usr/bin/'rsvg-convert --no-external-files -w 120 -h 61 -o '/tmp/transform_5a95aeb43c6b-1.png' '/tmp/localcopy_61a6c00091e1-1.svg' 2>&1""
2013-09-17 04:10:06 mw1154 commonswiki: thumbnail failed on mw1154: error 1 """" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=660x440 '/tmp/localcopy_cb6372f89daf-1.jpg'  -thumbnail '660x440!' -set comment 'File source: http://commons.wikimedia.org/wiki/File:Trevor_Parscal_December_2008.jpg' -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_f22fd870a3fc-1.jpg' 2>&1""
2013-09-17 04:10:06 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_f22fd870a3fc-1.jpg"". unlink() succeeded
2013-09-17 04:10:06 mw1157 commonswiki: thumbnail failed on mw1157: error 1 ""convert: no decode delegate for this image format `/a/magick-tmp/magick-NyMRfqeG' @ error/constitute.c/ReadImage/532.
convert: missing an image filename `/tmp/transform_6c0a3d0fd7c4-1.jpg' @ error/convert.c/ConvertImageCommand/3011."" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=120x53 ''  -thumbnail '120x53!' -set comment 'File source: http://commons.wikimedia.org/wiki/File:Banknote_5000_rubles_(1997)_front.jpg' -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_6c0a3d0fd7c4-1.jpg' 2>&1""
..
2013-09-17 04:13:59 mw1159 commonswiki: thumbnail failed on mw1159: error 1 ""Error reading SVG:Error domain 1 code 96 on line 1 column 17 of file:///tmp/localcopy_2362643f10ec-1.svg: Malformed declaration expecting version"" from ""'/usr/bin/'rsvg-convert --no-external-files -w 120 -h 96 -o '/tmp/transform_8ba6acf9d427-1.png' '/tmp/localcopy_2362643f10ec-1.svg' 2>&1""
2013-09-17 04:13:59 mw1154 commonswiki: thumbnail failed on mw1154: error 1 """" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=660x440 '/tmp/localcopy_babba88e51a4-1.jpg'  -thumbnail '660x440!' -set comment 'File source: http://commons.wikimedia.org/wiki/File:Trevor_Parscal_December_2008.jpg' -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_de7473e35169-1.jpg' 2>&1""
2013-09-17 04:13:59 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_de7473e35169-1.jpg"". unlink() succeeded
2013-09-17 04:14:01 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_55d5b98e5f7b-1.png"". unlink() succeeded",task_subcomment,"The entries in /a/mw-log/thumbnail.log are often hard to correlate since they use temporary file names. However it appears some (or all?) contain a MediaWiki File-namespace url as well.

I just got another HTTP 500 Internal Server Error and found the following entry:

URL: URL

Triggered from an  tag on URL when previewing an edit.


[04:11 UTC] krinkle at fluorine in /a/mw-log
$ tail thumbnail.log  -n500 | ack-grep Trevor -C 10

Bytes: 0xFF 0x27 0x20 0x69"" from ""'/usr/bin/'rsvg-convert --no-external-files -w 120 -h 61 -o '/tmp/transform_5a95aeb43c6b-1.png' '/tmp/localcopy_61a6c00091e1-1.svg' 2>&1""
2013-09-17 04:10:06 mw1154 commonswiki: thumbnail failed on mw1154: error 1 """" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=660x440 '/tmp/localcopy_cb6372f89daf-1.jpg'  -thumbnail '660x440!' -set comment 'File source: URL -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_f22fd870a3fc-1.jpg' 2>&1""
2013-09-17 04:10:06 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_f22fd870a3fc-1.jpg"". unlink() succeeded
2013-09-17 04:10:06 mw1157 commonswiki: thumbnail failed on mw1157: error 1 ""convert: no decode delegate for this image format CODE/tmp/transform_6c0a3d0fd7c4-1.jpg' @ error/convert.c/ConvertImageCommand/3011."" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=120x53 ''  -thumbnail '120x53!' -set comment 'File source: URL -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_6c0a3d0fd7c4-1.jpg' 2>&1""
..
2013-09-17 04:13:59 mw1159 commonswiki: thumbnail failed on mw1159: error 1 ""Error reading SVG:Error domain 1 code 96 on line 1 column 17 of file:///tmp/localcopy_2362643f10ec-1.svg: Malformed declaration expecting version"" from ""'/usr/bin/'rsvg-convert --no-external-files -w 120 -h 96 -o '/tmp/transform_8ba6acf9d427-1.png' '/tmp/localcopy_2362643f10ec-1.svg' 2>&1""
2013-09-17 04:13:59 mw1154 commonswiki: thumbnail failed on mw1154: error 1 """" from ""'/usr/bin/convert' -quality 80 -background white -define jpeg:size=660x440 '/tmp/localcopy_babba88e51a4-1.jpg'  -thumbnail '660x440!' -set comment 'File source: URL -depth 8 -sharpen '0x0.8'  -rotate -0   '/tmp/transform_de7473e35169-1.jpg' 2>&1""
2013-09-17 04:13:59 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_de7473e35169-1.jpg"". unlink() succeeded
2013-09-17 04:14:01 mw1154 commonswiki: Removing bad 0-byte thumbnail ""/tmp/transform_55d5b98e5f7b-1.png"". unlink() succeeded",BUG REPRODUCTION
254782,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"Btw, good debugging step would be for someone with shell to try running the convert command by hand (with limit.sh) to see what happens (e.g. if issue with cgroup config this would give an error that wouldn't be included in thumb log)

See also gerrit change 83974 which would give more useful error messages in certain circumstances (which may or may not help for the current situation)",task_subcomment,"Btw, good debugging step would be for someone with shell to try running the convert command by hand (with limit.sh) to see what happens (e.g. if issue with cgroup config this would give an error that wouldn't be included in thumb log)

See also gerrit change 83974 which would give more useful error messages in certain circumstances (which may or may not help for the current situation)",INVESTIGATION AND EXPLORATION
254775,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,*** Bug 54188 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54188 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
254767,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"(In reply to comment #5)
> reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
> 55424
> reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
> 111320

We pass things with \n's in them to wfDebugLog for the thumbnail log. I don't think we log successful thumbnailing events at all. So I think all that means is many of the thumbnail error log messages span several lines.",task_subcomment,"(In reply to comment #5)
QUOTE
QUOTE
QUOTE
QUOTE

We pass things with \n's in them to wfDebugLog for the thumbnail log. I don't think we log successful thumbnailing events at all. So I think all that means is many of the thumbnail error log messages span several lines.",SOLUTION DISCUSSION
254758,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"When you look at the 500 error message, its supposed to include all the stdout and stderr from convert. However these are empty. Perhaps https://gerrit.wikimedia.org/r/83974 would help debug the situation (including stderr from limit.sh in the 500 error message).",task_subcomment,"When you look at the 500 error message, its supposed to include all the stdout and stderr from convert. However these are empty. Perhaps GERRIT_URL would help debug the situation (including stderr from limit.sh in the 500 error message).",BUG REPRODUCTION
254751,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
55424
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
111320",task_subcomment,"reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
55424
reedy@fluorine:/a/mw-log$ grep -c mw1154 thumbnail.log
111320",BUG REPRODUCTION
254744,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"I just did a test on commons - visited a page with 200 images which I suspect were not previously rendered before (note: all were tiff files). 28 of them failed, all from mw1154. There's only 8 image scalars. 200/8 = 25, so its not hard to imagine this means all requests to mw1154 are failing.

Perhaps something is wrong with the cgroups config on that host (or something else that would prevent all shell commands from succeeding)

The ganglia graph seems to indicate that the CPU usage on that host has dropped off since friday - http://ganglia.wikimedia.org/latest/graph.php?g=cpu_report&z=xlarge&c=Image%20scalers%20eqiad&h=mw1154.eqiad.wmnet&l=e2ecff&v=&r=week&su=1&st=1378942982&x=0&n=0",task_subcomment,"I just did a test on commons - visited a page with 200 images which I suspect were not previously rendered before (note: all were tiff files). 28 of them failed, all from mw1154. There's only 8 image scalars. 200/8 = 25, so its not hard to imagine this means all requests to mw1154 are failing.

Perhaps something is wrong with the cgroups config on that host (or something else that would prevent all shell commands from succeeding)

The ganglia graph seems to indicate that the CPU usage on that host has dropped off since friday - URL",BUG REPRODUCTION
254734,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"Looks like mw1153 has stopped being so noisy, and it's now mw1154. Which I guess makes this a dupe of 53753

reedy@fluorine:/a/mw-log$ grep -c error thumbnail.log
324850
reedy@fluorine:/a/mw-log$ grep mw1153 thumbnail.log |grep -c error
22013
reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
54280
reedy@fluorine:/a/mw-log$ grep mw1155 thumbnail.log |grep -c error
22011
reedy@fluorine:/a/mw-log$ grep mw1156 thumbnail.log |grep -c error
21980
reedy@fluorine:/a/mw-log$ grep mw1157 thumbnail.log |grep -c error
21847
reedy@fluorine:/a/mw-log$ grep mw1158 thumbnail.log |grep -c error
22146
reedy@fluorine:/a/mw-log$ grep mw1159 thumbnail.log |grep -c error
21905
reedy@fluorine:/a/mw-log$ grep mw1160 thumbnail.log |grep -c error
22107",task_subcomment,"Looks like mw1153 has stopped being so noisy, and it's now mw1154. Which I guess makes this a dupe of 53753

reedy@fluorine:/a/mw-log$ grep -c error thumbnail.log
324850
reedy@fluorine:/a/mw-log$ grep mw1153 thumbnail.log |grep -c error
22013
reedy@fluorine:/a/mw-log$ grep mw1154 thumbnail.log |grep -c error
54280
reedy@fluorine:/a/mw-log$ grep mw1155 thumbnail.log |grep -c error
22011
reedy@fluorine:/a/mw-log$ grep mw1156 thumbnail.log |grep -c error
21980
reedy@fluorine:/a/mw-log$ grep mw1157 thumbnail.log |grep -c error
21847
reedy@fluorine:/a/mw-log$ grep mw1158 thumbnail.log |grep -c error
22146
reedy@fluorine:/a/mw-log$ grep mw1159 thumbnail.log |grep -c error
21905
reedy@fluorine:/a/mw-log$ grep mw1160 thumbnail.log |grep -c error
22107",BUG REPRODUCTION
254724,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"Always mw1154?

See also bug 53573, mw1153 was (not sure if it's changed) seemingly causing a lot more errors than its counterparts",task_subcomment,"Always mw1154?

See also bug 53573, mw1153 was (not sure if it's changed) seemingly causing a lot more errors than its counterparts",BUG REPRODUCTION
254712,Wikimedia thumbnail generator often returns HTTP 500 Internal Server Error,"See also bug 53573. (which was mostly mw1153)
-----
>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.

Thumbnail generation should be entirely independent of page view actions, so the scenario should definitely not matter",task_subcomment,"See also bug 53573. (which was mostly mw1153)
-----
QUOTE
QUOTE
QUOTE

Thumbnail generation should be entirely independent of page view actions, so the scenario should definitely not matter",SOLUTION DISCUSSION
55972,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","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",task_description,"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 CODE) 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**:
URL",INVESTIGATION AND EXPLORATION
250369,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 142320 merged by jenkins-bot:
Set wgGitInfoCacheDirectory to point to scap managed location

https://gerrit.wikimedia.org/r/142320",task_subcomment,"Change 142320 merged by jenkins-bot:
Set wgGitInfoCacheDirectory to point to scap managed location

GERRIT_URL",SOLUTION USAGE
250366,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Yay, thanks Bryan.",task_subcomment,"Yay, thanks Bryan.",ACTION ON ISSUE
250361,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 142319 merged by jenkins-bot:
Fix GitInfo cache file path computation and storage location

https://gerrit.wikimedia.org/r/142319",task_subcomment,"Change 142319 merged by jenkins-bot:
Fix GitInfo cache file path computation and storage location

GERRIT_URL",SOLUTION USAGE
250355,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 142320 had a related patch set uploaded by Krinkle:
Set wgGitInfoCacheDirectory to point to scap managed location

https://gerrit.wikimedia.org/r/142320",task_subcomment,"Change 142320 had a related patch set uploaded by Krinkle:
Set wgGitInfoCacheDirectory to point to scap managed location

GERRIT_URL",TASK PROGRESS
250350,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 142319 had a related patch set uploaded by BryanDavis:
Fix GitInfo cache file path computation and storage location

https://gerrit.wikimedia.org/r/142319",task_subcomment,"Change 142319 had a related patch set uploaded by BryanDavis:
Fix GitInfo cache file path computation and storage location

GERRIT_URL",TASK PROGRESS
250344,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","(In reply to Bryan Davis from comment #18)
> I'll spend some more time looking into why $IP isn't what I
> (and the paths inside $wgExtensionCredits) think it should be.

Today I learned that WebStart.php clears $IP and then recreates it from the first of the MW_INSTALL_PATH environment variable, `realpath( '.' )` or `dirname( __DIR__ )`. In beta, the realpath branch wins and sets $IP to '/srv/common-local/php-master'.",task_subcomment,"(In reply to Bryan Davis from comment #18)
QUOTE
QUOTE

Today I learned that WebStart.php clears $IP and then recreates it from the first of the MW_INSTALL_PATH environment variable, CODE or CODE. In beta, the realpath branch wins and sets $IP to '/srv/common-local/php-master'.",SOLUTION DISCUSSION
250338,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",So when I echo $IP from `mweval` in beta I get /srv/common-local/php-master but apparently inside Apache $IP is /usr/local/apache/common-local/php-master. The latter is a symlink to former. This difference is causing GitInfo::getCacheFilePath() to compute the wrong path for the cache file. I'll spend some more time looking into why $IP isn't what I (and the paths inside $wgExtensionCredits) think it should be.,task_subcomment,So when I echo $IP from CODE in beta I get /srv/common-local/php-master but apparently inside Apache $IP is /usr/local/apache/common-local/php-master. The latter is a symlink to former. This difference is causing GitInfo::getCacheFilePath() to compute the wrong path for the cache file. I'll spend some more time looking into why $IP isn't what I (and the paths inside $wgExtensionCredits) think it should be.,INVESTIGATION AND EXPLORATION
250332,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","I'm looking into this again and still can't figure out why http://en.wikipedia.beta.wmflabs.org/wiki/Special:Version isn't displaying the git SHA1 for extensions now.

Debugging using `mwscript eval.php --wiki=enwiki` on deployment-apache01 and deployment-apache02 shows that GitInfo can read the precomputed git information there:

    > $wgDebugLogGroups = array(); $wgDebugLogFile = 'php://stdout';
    > $gitinfo = new GitInfo($IP); $coreId = $gitinfo->getHeadSHA1();
    > $cache = wfGetCache( CACHE_ANYTHING );
    > $path = ""$IP/extensions/VisualEditor/VisualEditor.php"";
    > $memcKey = wfMemcKey( 'specialversion-ext-version-text', $path, $coreId );
    > echo $memcKey;
    enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251
    > var_dump( $cache->get( $memcKey ) );
    enwiki-bca38539: 649.4035  25.8M  [memcached] get(enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251)
    enwiki-bca38539: 649.4047  25.8M  [memcached] result: NOT FOUND
    bool(false)

    > $gitinfo = new GitInfo( dirname( $path ) );
    > echo $gitinfo->getHeadSHA1();
    fefd3a5d72c118993cc555f0a53a561f58a5fd19
    > echo $gitinfo->getHeadViewUrl();
    https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVisualEditor.git/fefd3a5d72c118993cc555f0a53a561f58a5fd19
    > echo $gitinfo->getHeadCommitDate();
    1400528579

I've verified that apache is running as the user ""apache"" on these nodes and that apache can read the *info.json files. The output of `eval.php` above shows that the php code is functional when executed from the cli. At this point I'm unable to understand why this output differs from SpecialVersion::getCreditsForExtension(). I'm sure I'm missing something in my analysis but I'm at a loss for what it is.",task_subcomment,"I'm looking into this again and still can't figure out why URL isn't displaying the git SHA1 for extensions now.

Debugging using CODE on deployment-apache01 and deployment-apache02 shows that GitInfo can read the precomputed git information there:

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
    enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251
QUOTE
    enwiki-bca38539: 649.4035  25.8M  [memcached] get(enwiki:specialversion-ext-version-text:/srv/common-local/php-master/extensions/VisualEditor/VisualEditor.php:49952a405014c89b239da3bcaea158c47faf8251)
    enwiki-bca38539: 649.4047  25.8M  [memcached] result: NOT FOUND
    bool(false)

QUOTE
QUOTE
    fefd3a5d72c118993cc555f0a53a561f58a5fd19
QUOTE
    URL
QUOTE
    1400528579

I've verified that apache is running as the user ""apache"" on these nodes and that apache can read the *info.json files. The output of CODE above shows that the php code is functional when executed from the cli. At this point I'm unable to understand why this output differs from SpecialVersion::getCreditsForExtension(). I'm sure I'm missing something in my analysis but I'm at a loss for what it is.",SOLUTION DISCUSSION
250326,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",Still not seeing data in Special:Version. There must be something that I'm not understanding about the environment. I can get the info via eval.php as shown above.,task_subcomment,Still not seeing data in Special:Version. There must be something that I'm not understanding about the environment. I can get the info via eval.php as shown above.,BUG REPRODUCTION
250320,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","I put a temporary hack in place on the beta nodes that run MediaWiki (apache0[12], jobrunner01, and videoscaler01) by symlinking $wgCacheDirectory/gitinfo to $IP/cache/gitinfo. This should make the git version data visible on the Special:Version page the next time that the MW-Core hash changes (memcache cache buster).

    deployment-apache01:~
    bd808$ mwscript eval.php --wiki=enwiki
    > var_dump( $gi = new GitInfo( ""$IP/extensions/VisualEditor"" ) );
    object(GitInfo)#113 (3) {
      [""basedir"":protected]=>
      NULL
      [""cacheFile"":protected]=>
      string(62) ""/tmp/mw-cache-master/gitinfo/info-extensions-VisualEditor.json""
      [""cache"":protected]=>
      array(6) {
        [""head""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""remoteURL""]=>
        string(70) ""https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor.git""
        [""branch""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""headCommitDate""]=>
        string(10) ""1399417572""
        [""headSHA1""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""@directory""]=>
        string(44) ""/a/common/php-master/extensions/VisualEditor""
      }
    }",task_subcomment,"I put a temporary hack in place on the beta nodes that run MediaWiki (apache0[12], jobrunner01, and videoscaler01) by symlinking $wgCacheDirectory/gitinfo to $IP/cache/gitinfo. This should make the git version data visible on the Special:Version page the next time that the MW-Core hash changes (memcache cache buster).

    deployment-apache01:~
    bd808$ mwscript eval.php --wiki=enwiki
QUOTE
    object(GitInfo)#113 (3) {
      [""basedir"":protected]=>
      NULL
      [""cacheFile"":protected]=>
      string(62) ""/tmp/mw-cache-master/gitinfo/info-extensions-VisualEditor.json""
      [""cache"":protected]=>
      array(6) {
        [""head""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""remoteURL""]=>
        string(70) ""URL
        [""branch""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""headCommitDate""]=>
        string(10) ""1399417572""
        [""headSHA1""]=>
        string(40) ""0496bd84506927039958cc683a35a5e3b5da2584""
        [""@directory""]=>
        string(44) ""/a/common/php-master/extensions/VisualEditor""
      }
    }",SOLUTION DISCUSSION
250315,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Patches are merged, but not sufficient. I didn't look into the value of $wgCacheDirectory in operations/mediawiki-config.git. In beta and the prod cluster we set the cache directory to a location outside of $IP rather than $IP/cache as I expected/coded the scap side to this change for.

I'll either need to add a new global to set/change the location where GitInfo looks for the cache or add yet another scap step to copy the generated files around to adjust for this.",task_subcomment,"Patches are merged, but not sufficient. I didn't look into the value of $wgCacheDirectory in operations/mediawiki-config.git. In beta and the prod cluster we set the cache directory to a location outside of $IP rather than $IP/cache as I expected/coded the scap side to this change for.

I'll either need to add a new global to set/change the location where GitInfo looks for the cache or add yet another scap step to copy the generated files around to adjust for this.",SOLUTION DISCUSSION
250310,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 130560 merged by jenkins-bot:
Precompute data for GitInfo

https://gerrit.wikimedia.org/r/130560",task_subcomment,"Change 130560 merged by jenkins-bot:
Precompute data for GitInfo

GERRIT_URL",ACTION ON ISSUE
250306,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 130498 merged by jenkins-bot:
Support precomputed data in GitInfo

https://gerrit.wikimedia.org/r/130498",task_subcomment,"Change 130498 merged by jenkins-bot:
Support precomputed data in GitInfo

GERRIT_URL",ACTION ON ISSUE
250302,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 130560 had a related patch set uploaded by BryanDavis:
Precompute data for GitInfo

https://gerrit.wikimedia.org/r/130560",task_subcomment,"Change 130560 had a related patch set uploaded by BryanDavis:
Precompute data for GitInfo

GERRIT_URL",ACTION ON ISSUE
250301,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","Change 130498 had a related patch set uploaded by BryanDavis:
Support precomputed data in GitInfo

https://gerrit.wikimedia.org/r/130498",task_subcomment,"Change 130498 had a related patch set uploaded by BryanDavis:
Support precomputed data in GitInfo

GERRIT_URL",SOLUTION USAGE
250299,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",I'm working on a fix for this problem by adding a step to scap that precomputes the information needed by GitInfo.php to json files that can be synced to the apaches. This would fix the path change issue and should slightly reduce runtime cost of Special:Version and other pages that use GitInfo. It would also allow us to drop syncing of the .git directories all together if we wanted.,task_subcomment,I'm working on a fix for this problem by adding a step to scap that precomputes the information needed by GitInfo.php to json files that can be synced to the apaches. This would fix the path change issue and should slightly reduce runtime cost of Special:Version and other pages that use GitInfo. It would also allow us to drop syncing of the .git directories all together if we wanted.,SOLUTION DISCUSSION
250297,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","(In reply to Bryan Davis from comment #2)
> I can't find any reason by grepping in operations/puppet that the general
> mw* nodes would have /a and/or /a/common created but /a/common exists as an
> empty directory on all of them that I randomly sampled.

I eventually found the puppet code that creates /a/common as an empty directory on many hosts. The misc::deployment::vars class which in included from the misc::deployment::scap_scripts class creates the directory if it doesn't exist [0].

[0]: https://github.com/wikimedia/operations-puppet/blob/c5b8fa0631d3b28b6ca062e313b98e80d7325d80/manifests/misc/deployment.pp#L368-L374",task_subcomment,"(In reply to Bryan Davis from comment #2)
QUOTE
QUOTE
QUOTE

I eventually found the puppet code that creates /a/common as an empty directory on many hosts. The misc::deployment::vars class which in included from the misc::deployment::scap_scripts class creates the directory if it doesn't exist [0].

[0]: URL",SOLUTION DISCUSSION
250291,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","(In reply to James Forrester from comment #6)
> Could we just have scap re-write the .git files (or have them be relative
> and not absolute in the first place)?

Having them be relative in the first place would really be nicest. Do we have a git guru who could look into that?

I had the same idea about rewriting the .git files as a scap step. It shouldn't be too hard to do. Because of the way that scap works right now we'd need to do this on each host as a post-update step similarly to the way that the l10n JSON intermediate files are recompiled into CDB files.",task_subcomment,"(In reply to James Forrester from comment #6)
QUOTE
QUOTE

Having them be relative in the first place would really be nicest. Do we have a git guru who could look into that?

I had the same idea about rewriting the .git files as a scap step. It shouldn't be too hard to do. Because of the way that scap works right now we'd need to do this on each host as a post-update step similarly to the way that the l10n JSON intermediate files are recompiled into CDB files.",SOLUTION DISCUSSION
250285,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",Could we just have scap re-write the .git files (or have them be relative and not absolute in the first place)?,task_subcomment,Could we just have scap re-write the .git files (or have them be relative and not absolute in the first place)?,SOLUTION DISCUSSION
250278,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","This bug affects the beta environment now that scap is being used to deploy code there. The ideas for creating symlinks to restore the scame directory structure that is used on the deploy host (deployment-bastion.eqiad.wfmlabs) make even less sense in beta. Here's an example .git file from an extension there:

    gitdir: /mnt/srv/scap-stage-dir/php-master/extensions/.git/modules/MultimediaViewer",task_subcomment,"This bug affects the beta environment now that scap is being used to deploy code there. The ideas for creating symlinks to restore the scame directory structure that is used on the deploy host (deployment-bastion.eqiad.wfmlabs) make even less sense in beta. Here's an example .git file from an extension there:

    gitdir: /mnt/srv/scap-stage-dir/php-master/extensions/.git/modules/MultimediaViewer",SOLUTION DISCUSSION
250273,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",*** Bug 62760 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 62760 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
250269,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link",*** Bug 53070 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53070 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
250264,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","(In reply to Krinkle from comment #0)
> 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).

/a/common is the rsync server source directory on tin for scap. This directory is used to prepare the files that will be pushed out by scap to the members of the /etc/dsh/group/scap-proxies group and then subsequently to the rest of the cluster.

The misc::deployment::vars puppet class ensures that this directory is created on all hosts where the misc::deployment::scap_scripts puppet class is applied. The misc::deployment::scap_scripts class is applied directly to arsenic, hume, terbium, and tin in site.pp. It's also applied indirectly on the snapshot* servers by the mediawiki::sync class.

I can't find any reason by grepping in operations/puppet that the general mw* nodes would have /a and/or /a/common created but /a/common exists as an empty directory on all of them that I randomly sampled. It seems like it should be possible to add some puppet config (maybe in role::applicationserver::webserver?) to ensure that the /a directory is created and then symlink /a/common to /usr/local/apache/common.",task_subcomment,"(In reply to Krinkle from comment #0)
QUOTE
QUOTE

/a/common is the rsync server source directory on tin for scap. This directory is used to prepare the files that will be pushed out by scap to the members of the /etc/dsh/group/scap-proxies group and then subsequently to the rest of the cluster.

The misc::deployment::vars puppet class ensures that this directory is created on all hosts where the misc::deployment::scap_scripts puppet class is applied. The misc::deployment::scap_scripts class is applied directly to arsenic, hume, terbium, and tin in site.pp. It's also applied indirectly on the snapshot* servers by the mediawiki::sync class.

I can't find any reason by grepping in operations/puppet that the general mw* nodes would have /a and/or /a/common created but /a/common exists as an empty directory on all of them that I randomly sampled. It seems like it should be possible to add some puppet config (maybe in role::applicationserver::webserver?) to ensure that the /a directory is created and then symlink /a/common to /usr/local/apache/common.",SOLUTION DISCUSSION
250258,"[scap] Deployment: Repository .git is synchronised fine, but is broken for submodules because of hardcoded gitdir link","(In reply to comment #0)
> 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).

fluorine",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE

fluorine",ACTION ON ISSUE
55895,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"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",task_description,"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",BUG REPRODUCTION
246115,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"(In reply to christian from comment #28)
> Since this bug has been around for a while and has affected quite some
> people, I've been asked to give a short explanation of the root issue
> and what SSHD-330 does.
> 
> Gerrit uses Apache Mina's SSHD [1] as ssh server. When connecting to
> gerrit through ssh, this ssh server uses Java's own crypto/security
> implementations to negotiate session keys (i.e.: different for each
> connection attempt) with the client. Java's default provider yielded
> those session keys without leading zero bytes, and Apache Mina's SSHD
> relied on no leading zero bytes being present.
> 
> But at some point Java [2] changed behaviour and is no longer
> stripping leading zero bytes, but Apache Mina SSHD still relied on no
> leading zero bytes being present. Hence assumptions mismatched and
> caused the issue.
> 
> The Java we use at gerrit.wikimedia.org is recent enough to no longer
> strip leading zero bytes. So when connecting to our gerrit through
> ssh, either
> 
> * the negotiated session key starts with a non-zero byte, and
>   everything works nicely. This case happens most of the time.
> 
> * the negotiated session key starts with a zero byte. Then gerrit's
>   built-in Apache Mina SSHD falsely treats the key as if there were no
>   leading zero bytes and the connection setup with the client fails.
> 
> SSHD-330 adds stripping of leading zero bytes from the session key to
> Apache Mina SSHD and thereby fixes the issue we are seeing.
> 
> ------
> 
> There was recently some FUD around OpenSSL generated keys not being
> affected. That did not work for me, and I do not see in code how this
> would make a difference.
> 
> Also, there was some recent discussion around extracting the keys from
> the keystore to proper files. I did not get a chance to try that, but
> that could do the trick too ... indirectly.
> Because in order to get gerrit to use keys from separate files, one
> needs to install BouncyCastle libraries to gerrit. BouncyCastle will
> act as provider for the needed security/crypto functionality and
> get used instead of Java's default providers. As the BouncyCastle
> providers (for now) also strip the leading zero bytes, that could
> work out.
> 
> Regardless, having Apache Mina SSHD to strip leading zero bytes seems
> most reliable, so we backported the Apache Mina SSHD's upstream fix to
> the version used in our gerrit, and rebuilt gerrit using that custom
> built Apache Mina SSHD.
> 
> [1] https://mina.apache.org/sshd-project/
> [2] I know that OpenJDK versions up to
>   OpenJDK Runtime Environment (IcedTea7 2.2.1) (Gentoo build 1.7.0_05-b21)
> work and the default providers strip the leading zeros, while the ones from
>   OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
> do not strip them.
> 
> 
> Thanks Krinkle for the pointer to SSHD-330!

And thank you for the analysis and the informative summary -- well done!",task_subcomment,"(In reply to christian from comment #28)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

And thank you for the analysis and the informative summary -- well done!",ACTION ON ISSUE
246109,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',<3,task_subcomment,<3,SOCIAL CONVERSATION
246101,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',The fix has been deployed at gerrit.wikimedia.org.,task_subcomment,The fix has been deployed at gerrit.wikimedia.org.,ACTION ON ISSUE
246093,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Change 143388 merged by Chad:
Upgrade sshd to include the fix for hash mismatch

https://gerrit.wikimedia.org/r/143388",task_subcomment,"Change 143388 merged by Chad:
Upgrade sshd to include the fix for hash mismatch

GERRIT_URL",ACTION ON ISSUE
246086,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Since this bug has been around for a while and has affected quite some
people, I've been asked to give a short explanation of the root issue
and what SSHD-330 does.

Gerrit uses Apache Mina's SSHD [1] as ssh server. When connecting to
gerrit through ssh, this ssh server uses Java's own crypto/security
implementations to negotiate session keys (i.e.: different for each
connection attempt) with the client. Java's default provider yielded
those session keys without leading zero bytes, and Apache Mina's SSHD
relied on no leading zero bytes being present.

But at some point Java [2] changed behaviour and is no longer
stripping leading zero bytes, but Apache Mina SSHD still relied on no
leading zero bytes being present. Hence assumptions mismatched and
caused the issue.

The Java we use at gerrit.wikimedia.org is recent enough to no longer
strip leading zero bytes. So when connecting to our gerrit through
ssh, either

* the negotiated session key starts with a non-zero byte, and
  everything works nicely. This case happens most of the time.

* the negotiated session key starts with a zero byte. Then gerrit's
  built-in Apache Mina SSHD falsely treats the key as if there were no
  leading zero bytes and the connection setup with the client fails.

SSHD-330 adds stripping of leading zero bytes from the session key to
Apache Mina SSHD and thereby fixes the issue we are seeing.

------

There was recently some FUD around OpenSSL generated keys not being
affected. That did not work for me, and I do not see in code how this
would make a difference.

Also, there was some recent discussion around extracting the keys from
the keystore to proper files. I did not get a chance to try that, but
that could do the trick too ... indirectly.
Because in order to get gerrit to use keys from separate files, one
needs to install BouncyCastle libraries to gerrit. BouncyCastle will
act as provider for the needed security/crypto functionality and
get used instead of Java's default providers. As the BouncyCastle
providers (for now) also strip the leading zero bytes, that could
work out.

Regardless, having Apache Mina SSHD to strip leading zero bytes seems
most reliable, so we backported the Apache Mina SSHD's upstream fix to
the version used in our gerrit, and rebuilt gerrit using that custom
built Apache Mina SSHD.

[1] https://mina.apache.org/sshd-project/
[2] I know that OpenJDK versions up to
  OpenJDK Runtime Environment (IcedTea7 2.2.1) (Gentoo build 1.7.0_05-b21)
work and the default providers strip the leading zeros, while the ones from
  OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
do not strip them.


Thanks Krinkle for the pointer to SSHD-330!",task_subcomment,"Since this bug has been around for a while and has affected quite some
people, I've been asked to give a short explanation of the root issue
and what SSHD-330 does.

Gerrit uses Apache Mina's SSHD [1] as ssh server. When connecting to
gerrit through ssh, this ssh server uses Java's own crypto/security
implementations to negotiate session keys (i.e.: different for each
connection attempt) with the client. Java's default provider yielded
those session keys without leading zero bytes, and Apache Mina's SSHD
relied on no leading zero bytes being present.

But at some point Java [2] changed behaviour and is no longer
stripping leading zero bytes, but Apache Mina SSHD still relied on no
leading zero bytes being present. Hence assumptions mismatched and
caused the issue.

The Java we use at gerrit.wikimedia.org is recent enough to no longer
strip leading zero bytes. So when connecting to our gerrit through
ssh, either

* the negotiated session key starts with a non-zero byte, and
  everything works nicely. This case happens most of the time.

* the negotiated session key starts with a zero byte. Then gerrit's
  built-in Apache Mina SSHD falsely treats the key as if there were no
  leading zero bytes and the connection setup with the client fails.

SSHD-330 adds stripping of leading zero bytes from the session key to
Apache Mina SSHD and thereby fixes the issue we are seeing.

------

There was recently some FUD around OpenSSL generated keys not being
affected. That did not work for me, and I do not see in code how this
would make a difference.

Also, there was some recent discussion around extracting the keys from
the keystore to proper files. I did not get a chance to try that, but
that could do the trick too ... indirectly.
Because in order to get gerrit to use keys from separate files, one
needs to install BouncyCastle libraries to gerrit. BouncyCastle will
act as provider for the needed security/crypto functionality and
get used instead of Java's default providers. As the BouncyCastle
providers (for now) also strip the leading zero bytes, that could
work out.

Regardless, having Apache Mina SSHD to strip leading zero bytes seems
most reliable, so we backported the Apache Mina SSHD's upstream fix to
the version used in our gerrit, and rebuilt gerrit using that custom
built Apache Mina SSHD.

[1] URL
[2] I know that OpenJDK versions up to
  OpenJDK Runtime Environment (IcedTea7 2.2.1) (Gentoo build 1.7.0_05-b21)
work and the default providers strip the leading zeros, while the ones from
  OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-1ubuntu1~0.12.04.2)
do not strip them.


Thanks Krinkle for the pointer to SSHD-330!",SOLUTION DISCUSSION
246077,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"I have upgraded Gerrit on my test instance integration-dev.eqiad.wmflabs . There is no more any hash mismatch triggered when running for a while:

while true; do ssh -p 29418 localhost; done;",task_subcomment,"I have upgraded Gerrit on my test instance integration-dev.eqiad.wmflabs . There is no more any hash mismatch triggered when running for a while:

while true; do ssh -p 29418 localhost; done;",TASK PROGRESS
246068,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"(In reply to Antoine ""hashar"" Musso from comment #25)
> Christian could you possibly providee a gerrit.war  that has the patch ?

Sure. For the next 2 weeks, you can fetch it from

  http://quelltextlich.at/gerrit-2.8.1-4-ga1048ce.war

> I
> would like to test it out on the labs instance I am using for CI dev.

Seeing the description of SSHD-330 allowed me to come up with an environment
that allows to reproduce the bug. There, our deployed gerrit war failed for
14 of 10000 connection attempts. The war I linked above showed 0 failures for
10000 connection attempts.

^d already said he'll discuss deploying the war with greg-g. So we'll
hopefully see it live soon.",task_subcomment,"(In reply to Antoine ""hashar"" Musso from comment #25)
QUOTE

Sure. For the next 2 weeks, you can fetch it from

  URL

QUOTE
QUOTE

Seeing the description of SSHD-330 allowed me to come up with an environment
that allows to reproduce the bug. There, our deployed gerrit war failed for
14 of 10000 connection attempts. The war I linked above showed 0 failures for
10000 connection attempts.

^d already said he'll discuss deploying the war with greg-g. So we'll
hopefully see it live soon.",SOLUTION DISCUSSION
246058,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',Christian could you possibly providee a gerrit.war  that has the patch ? I would like to test it out on the labs instance I am using for CI dev. Thanks!,task_subcomment,Christian could you possibly providee a gerrit.war  that has the patch ? I would like to test it out on the labs instance I am using for CI dev. Thanks!,TASK PROGRESS
246050,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Change 143388 had a related patch set uploaded by QChris:
Upgrade sshd to include the fix for hash mismatch

https://gerrit.wikimedia.org/r/143388",task_subcomment,"Change 143388 had a related patch set uploaded by QChris:
Upgrade sshd to include the fix for hash mismatch

GERRIT_URL",TASK PROGRESS
246041,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"The description of the SSHD-330 issue explains pretty much every aspect of
the bug that we experienced.

From it's sporadic nature to the ways some people could reproduce, but others
couldn't.

I'll see to preparing a new gerrit release ... hopefully we can get something
deployed around that.",task_subcomment,"The description of the SSHD-330 issue explains pretty much every aspect of
the bug that we experienced.

From it's sporadic nature to the ways some people could reproduce, but others
couldn't.

I'll see to preparing a new gerrit release ... hopefully we can get something
deployed around that.",SOLUTION DISCUSSION
246035,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"The google group topic mentioned this issue in Apache mina-sshd (upstream from Gerrit):

https://issues.apache.org/jira/browse/SSHD-330

Which has been fixed in https://git-wip-us.apache.org/repos/asf?p=mina-sshd.git;a=commit;h=2aed686bdb21681a421033c6ee5997e5cd8a9a83

If that is indeed the root issue, we them to make a minor release and Gerrit to upgrade to it.",task_subcomment,"The google group topic mentioned this issue in Apache mina-sshd (upstream from Gerrit):

URL

Which has been fixed in URL

If that is indeed the root issue, we them to make a minor release and Gerrit to upgrade to it.",FUTURE PLAN
246030,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"**paul.bourke** wrote:

Hi, I've been able to reproduce this on a local Gerrit instance quite reliably by running the following:

while true; do ssh  -p 29418; done

A workaround that does work is to use the bouncy castle SSL library.  See the following thread for more info: https://groups.google.com/forum/#!topic/repo-discuss/JE7OM6o7DMs",task_subcomment,"**paul.bourke** wrote:

Hi, I've been able to reproduce this on a local Gerrit instance quite reliably by running the following:

while true; do ssh  -p 29418; done

A workaround that does work is to use the bouncy castle SSL library.  See the following thread for more info: URL",BUG REPRODUCTION
246027,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Bartosz: there is no need more for more examples.  We have traces of those errors in Zuul log and it happens a couple time per day.

Marcin: we could tcpdump it if only we had a way to reliably reproduce the issue :-(",task_subcomment,"Bartosz: there is no need more for more examples.  We have traces of those errors in Zuul log and it happens a couple time per day.

Marcin: we could tcpdump it if only we had a way to reliably reproduce the issue :-(",TASK PROGRESS
246024,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Two examples from just today:
* https://gerrit.wikimedia.org/r/#/c/139807/
* https://gerrit.wikimedia.org/r/#/c/140046/",task_subcomment,"Two examples from just today:
* URL
* URL",WORKAROUNDS
246021,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',Today again: https://gerrit.wikimedia.org/r/#/c/139047/,task_subcomment,Today again: URL,ACTION ON ISSUE
246017,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Could somebody tcpdump it? It seems it me more like a broken (suddenly terminated) connection, probably occuring (mostly) early in the SSH negotiation phase.",task_subcomment,"Could somebody tcpdump it? It seems it me more like a broken (suddenly terminated) connection, probably occuring (mostly) early in the SSH negotiation phase.",INVESTIGATION AND EXPLORATION
246012,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Subsided for a while, then started happening a bit more often for me locally. Example in Gerrit from today: https://gerrit.wikimedia.org/r/#/c/138992/1",task_subcomment,"Subsided for a while, then started happening a bit more often for me locally. Example in Gerrit from today: URL",BUG REPRODUCTION
246006,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"This continues to happen, nearly daily.

You could probably get a good list of affected changesets by grepping logs of #wikimedia-dev for my name and ""ignore jenkins"" :/",task_subcomment,"This continues to happen, nearly daily.

You could probably get a good list of affected changesets by grepping logs of #wikimedia-dev for my name and ""ignore jenkins"" :/",TASK PROGRESS
246002,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Another example, this time with the job that sync VisualEditor in mediawiki/extensions.git.  The merge of https://gerrit.wikimedia.org/r/#/c/111608/ triggered job http://integration.wikimedia.org/ci/job/mwext-VisualEditor-sync-gerrit/61/console which shows:

  ssh -i /var/lib/jenkins/.ssh/jenkins-mwext-sync_id_rsa \
    -p 29418 jenkins-mwext-sync@gerrit.wikimedia.org \
    'gerrit review --code-review +2 --verified +2 --submit b519550809bba725b017281fe6c33c4c2fd123c1'
  hash mismatch
  key_verify failed for server_host_key",task_subcomment,"Another example, this time with the job that sync VisualEditor in mediawiki/extensions.git.  The merge of URL triggered job URL which shows:

  ssh -i /var/lib/jenkins/.ssh/jenkins-mwext-sync_id_rsa \
    -p 29418 jenkins-mwext-sync@gerrit.wikimedia.org \
    'gerrit review --code-review +2 --verified +2 --submit b519550809bba725b017281fe6c33c4c2fd123c1'
  hash mismatch
  key_verify failed for server_host_key",BUG REPRODUCTION
245998,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"(In reply to comment #12)
> Is this related: https://gerrit.wikimedia.org/r/#/c/107036/ ?

Looking at Zuul debugging log on gallium.wikimedia.org it is a different issue. Filled another bug 59991 for it. Seems to be an issue in the python git module.",task_subcomment,"(In reply to comment #12)
QUOTE

Looking at Zuul debugging log on gallium.wikimedia.org it is a different issue. Filled another bug 59991 for it. Seems to be an issue in the python git module.",BUG REPRODUCTION
245994,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',Is this related: https://gerrit.wikimedia.org/r/#/c/107036/ ?,task_subcomment,Is this related: URL ?,ACTION ON ISSUE
245992,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Also got one today in command line.

FYI: the -1s in Jenkins caused by this are very confusing.",task_subcomment,"Also got one today in command line.

FYI: the -1s in Jenkins caused by this are very confusing.",BUG REPRODUCTION
245990,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"That does happen once or two per day on Zuul. Usually ""hash mismatch"" errors though we had some host key verification failed on Nov 20th.",task_subcomment,"That does happen once or two per day on Zuul. Usually ""hash mismatch"" errors though we had some host key verification failed on Nov 20th.",BUG REPRODUCTION
245988,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',*** Bug 57483 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 57483 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
245985,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"(In reply to comment #7)
> Just happened to me w/operations/puppet.
> 
> $ git pull
> hash mismatch
> key_verify failed for server_host_key
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

We see similar errors very regularly when updating 600 or so extension repos at translatewiki.net. I'm pretty certain that we have the correct access rights with L10n-bot, have the correct access rights at the local machine, and have consistent scripting up update the repos.

A run I did just now resulted in the following errors:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/CategoryMagicWords failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/ReplaceSet failed to update

Just to make sure that it wasn't me configuring the two above repos incorrectly, I ran the updates again. This time with the following result:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/DidYouKnow failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/FormatDates failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/GoogleDocTag failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/InviteSignup failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/LightweightRDFa failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/Numbertext failed to update

/resources/siebrand/mediawiki-extensions/extensions/NumberOfWikis failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/PageLanguage failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/SidebarDonateBox failed to update

hash mismatch
key_verify failed for server_host_key
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/UserStatus failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/VersionView failed to update



To compare, when updating repos on localhost form GitHub, I've not seen a similar error once.",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

We see similar errors very regularly when updating 600 or so extension repos at translatewiki.net. I'm pretty certain that we have the correct access rights with L10n-bot, have the correct access rights at the local machine, and have consistent scripting up update the repos.

A run I did just now resulted in the following errors:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/CategoryMagicWords failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/ReplaceSet failed to update

Just to make sure that it wasn't me configuring the two above repos incorrectly, I ran the updates again. This time with the following result:

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/DidYouKnow failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/FormatDates failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/GoogleDocTag failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/InviteSignup failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/LightweightRDFa failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/Numbertext failed to update

/resources/siebrand/mediawiki-extensions/extensions/NumberOfWikis failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/PageLanguage failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch origin
/resources/siebrand/mediawiki-extensions/extensions/SidebarDonateBox failed to update

hash mismatch
key_verify failed for server_host_key
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/UserStatus failed to update

Permission denied (publickey).
fatal: The remote end hung up unexpectedly
error: Could not fetch gerrit
/resources/siebrand/mediawiki-extensions/extensions/VersionView failed to update



To compare, when updating repos on localhost form GitHub, I've not seen a similar error once.",INVESTIGATION AND EXPLORATION
245981,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Just happened to me w/operations/puppet.

$ git pull
hash mismatch
key_verify failed for server_host_key
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.",task_subcomment,"Just happened to me w/operations/puppet.

$ git pull
hash mismatch
key_verify failed for server_host_key
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.",BUG REPRODUCTION
245975,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',(Worked for me when I tried again),task_subcomment,(Worked for me when I tried again),SOLUTION USAGE
245968,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"Several reports of this in the last few days. Reporters include Krenair, YuviPanda, and Krinkle.",task_subcomment,"Several reports of this in the last few days. Reporters include Krenair, YuviPanda, and Krinkle.",BUG REPRODUCTION
245960,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',Still seeing this error randomly.,task_subcomment,Still seeing this error randomly.,BUG REPRODUCTION
245951,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"(In reply to comment #2)
> We changed IP addresses when moving servers (shouldn't have to ever happen
> again), so please check your known_hosts for any outdated entries that you
> can remove.

How can I identify outdated entries? There are no IP addresses in known_hosts. Sample entry:

 |1|umKi+qzw6pf8uXi/Z6/KtqlisCw=|YFoX/CdDjXhcVUVJ803EiP9nyro= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2JmNg8ir9QvWwmS/C2k0PEqty1O26D0Nq24YGKC5jq1cr/0a92Pk7wa9FMMM/2O88bbe6rXZUPBKzDX1vVtYD+5vR4/c1XTnHWlNJ9sd6xSYjHhznqYs81VnjGMCLMPV1GhlIfUZsnQ+
w1FaQUvJe39TEtwADA7ZOFAfT0M/Oqk=",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE

How can I identify outdated entries? There are no IP addresses in known_hosts. Sample entry:

 |1|umKi+qzw6pf8uXi/Z6/KtqlisCw=|YFoX/CdDjXhcVUVJ803EiP9nyro= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA2JmNg8ir9QvWwmS/C2k0PEqty1O26D0Nq24YGKC5jq1cr/0a92Pk7wa9FMMM/2O88bbe6rXZUPBKzDX1vVtYD+5vR4/c1XTnHWlNJ9sd6xSYjHhznqYs81VnjGMCLMPV1GhlIfUZsnQ+
w1FaQUvJe39TEtwADA7ZOFAfT0M/Oqk=",ACTION ON ISSUE
245945,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',"So, this sounds like you've got an old entry in your known_hosts files pointing to the old box.

We changed IP addresses when moving servers (shouldn't have to ever happen again), so please check your known_hosts for any outdated entries that you can remove.",task_subcomment,"So, this sounds like you've got an old entry in your known_hosts files pointing to the old box.

We changed IP addresses when moving servers (shouldn't have to ever happen again), so please check your known_hosts for any outdated entries that you can remove.",WORKAROUNDS
245939,Gerrit SSH: Intermittent key_verify failed for server_host_key and 'hash mismatch',We retained the same key for exactly this reason...,task_subcomment,We retained the same key for exactly this reason...,SOLUTION DISCUSSION
55865,Review and deploy BetaFeatures extension,"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",task_description,"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**: URL",FUTURE PLAN
244040,Review and deploy BetaFeatures extension,"We deployed to MediaWiki.org already. We were trying to deploy VectorBeta yesterday, but as you said, it crapped out - hence, bug 55749 stays open but this one got closed (and should have been closed much earlier)",task_subcomment,"We deployed to MediaWiki.org already. We were trying to deploy VectorBeta yesterday, but as you said, it crapped out - hence, bug 55749 stays open but this one got closed (and should have been closed much earlier)",ACTION ON ISSUE
244034,Review and deploy BetaFeatures extension,"Because this was supposed to happen yesterday, but the servers crapped themselves. I think the new deployment date is Monday.",task_subcomment,"Because this was supposed to happen yesterday, but the servers crapped themselves. I think the new deployment date is Monday.",TASK PROGRESS
244029,Review and deploy BetaFeatures extension,Why is this bug marked fixed?,task_subcomment,Why is this bug marked fixed?,BUG REPRODUCTION
244026,Review and deploy BetaFeatures extension,Ready to deploy.,task_subcomment,Ready to deploy.,TASK PROGRESS
244019,Review and deploy BetaFeatures extension,"Adding dependencies - we're not deploying BF until the three listed extensions are also deployable. We're hoping that'll happen by Thursday morning.

AWAY!!!!",task_subcomment,"Adding dependencies - we're not deploying BF until the three listed extensions are also deployable. We're hoping that'll happen by Thursday morning.

AWAY!!!!",TASK PROGRESS
244011,Review and deploy BetaFeatures extension,"Security fixes in https://gerrit.wikimedia.org/r/86023 should close the review portion of this bug - ready for deployment.

We'll discuss deployment strategy after that patch is merged and we have a better idea of what we want out of it.",task_subcomment,"Security fixes in GERRIT_URL should close the review portion of this bug - ready for deployment.

We'll discuss deployment strategy after that patch is merged and we have a better idea of what we want out of it.",TASK PROGRESS
244005,Review and deploy BetaFeatures extension,"Design review is done - security review only remaining review.

== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: yes
Security Review: no
Screencast (if applicable): N/A
Community support: I believe so",task_subcomment,"Design review is done - security review only remaining review.

== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: yes
Security Review: no
Screencast (if applicable): N/A
Community support: I believe so",SOLUTION USAGE
243999,Review and deploy BetaFeatures extension,"Reedy did architecture/performance review. Chris will be doing security review sometime early next week. Design review is being finalized as we speak.

We'll be rolling this out in tandem with a bunch of other changes, so the deployment won't happen right away, and it will happen in stages (like Notifications, basically).",task_subcomment,"Reedy did architecture/performance review. Chris will be doing security review sometime early next week. Design review is being finalized as we speak.

We'll be rolling this out in tandem with a bunch of other changes, so the deployment won't happen right away, and it will happen in stages (like Notifications, basically).",ACTION ON ISSUE
243993,Review and deploy BetaFeatures extension,"Hello, this is a quasi-automated-but-not-really message:

I am reviewing all tracking bugs for extensions to review and deploy to WMF servers. See the list here:
https://bugzilla.wikimedia.org/showdependencytree.cgi?id=31235&hide_resolved=1

The [[mw:Review queue]] page lists the steps necessary to complete the review. I have copied them below and done some initial filling out based on what I can easily gleen from this bug and any linked to sources that are obvious. If I miss something/state something false, please do correct me.

Also, if you haven't yet done so, please review the information on and linked to from:
https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment


== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: I believe so",task_subcomment,"Hello, this is a quasi-automated-but-not-really message:

I am reviewing all tracking bugs for extensions to review and deploy to WMF servers. See the list here:
URL

The [[mw:Review queue]] page lists the steps necessary to complete the review. I have copied them below and done some initial filling out based on what I can easily gleen from this bug and any linked to sources that are obvious. If I miss something/state something false, please do correct me.

Also, if you haven't yet done so, please review the information on and linked to from:
URL


== TODO/Check list ==
Extension page on mediawiki.org: yes 
Bugzilla component: yes
Extension in Gerrit: yes
Design Review: yes
Archeticecture/Performance Review: no
Security Review: no
Screencast (if applicable): no
Community support: I believe so",SOLUTION USAGE
55836,Commit missing from mediawiki/exentions/MassMessage repo,"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",task_description,"URL - sha1: 8587e2e4b4f90ca9cdba0f39e647b235921a5ae8

Missing on git.wm.o, gerrit, github:

URL

URL 

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 URL
b9ccd1c Autocomplete suggestions for spamlist input
3027dc6 Localisation updates from URL
8d106e1 Localisation updates from URL
[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",BUG REPRODUCTION
242282,Commit missing from mediawiki/exentions/MassMessage repo,"

*** This bug has been marked as a duplicate of bug 53841 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 53841 ***",BUG REPRODUCTION
242278,Commit missing from mediawiki/exentions/MassMessage repo,"(In reply to comment #7)
> (In reply to comment #6)
> > I don't think my issue is the same since the commit is missing from both the
> > web viewers on git.wm.o and github.
> > 
> > I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org
> > when cloning.
> 
> So what happened here was the change was merged without a merge commit. Will
> require some manual wrangling one way or the other to fix.

Maybe I'm misunderstanding, but the commit was merged just fine. It didn't need a merge commit since at the time, it was directly on top of the current HEAD. It was replicated to github fine, and I pulled locally using my gerrit remote. When the upgrade happened it vanished. At that point, it was missing from gerrit.wm.o, but it was still visible on github, until the l10n-bot updated the translations, off of the HEAD on gerrit, which was (force?) pushed to github and overrode the ""fix typo"" commit.",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Maybe I'm misunderstanding, but the commit was merged just fine. It didn't need a merge commit since at the time, it was directly on top of the current HEAD. It was replicated to github fine, and I pulled locally using my gerrit remote. When the upgrade happened it vanished. At that point, it was missing from gerrit.wm.o, but it was still visible on github, until the l10n-bot updated the translations, off of the HEAD on gerrit, which was (force?) pushed to github and overrode the ""fix typo"" commit.",SOLUTION DISCUSSION
242275,Commit missing from mediawiki/exentions/MassMessage repo,"(In reply to comment #6)
> I don't think my issue is the same since the commit is missing from both the
> web viewers on git.wm.o and github.
> 
> I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org
> when cloning.

So what happened here was the change was merged without a merge commit. Will require some manual wrangling one way or the other to fix.",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

So what happened here was the change was merged without a merge commit. Will require some manual wrangling one way or the other to fix.",ACTION ON ISSUE
242272,Commit missing from mediawiki/exentions/MassMessage repo,"I don't think my issue is the same since the commit is missing from both the web viewers on git.wm.o and github.

I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org when cloning.",task_subcomment,"I don't think my issue is the same since the commit is missing from both the web viewers on git.wm.o and github.

I'm not sure I've hardcoded an IP anywhere, I just use gerrit.wikimedia.org when cloning.",BUG REPRODUCTION
242268,Commit missing from mediawiki/exentions/MassMessage repo,"To the original reporter: can you confirm the IP address you are using for gerrit.wikimedia.org?  That would let us figure out if you have the same issue I was having, or a different one.",task_subcomment,"To the original reporter: can you confirm the IP address you are using for gerrit.wikimedia.org?  That would let us figure out if you have the same issue I was having, or a different one.",ACTION ON ISSUE
242263,Commit missing from mediawiki/exentions/MassMessage repo,Mea culpa -- my bug (in comment 2) was caused by an out-of-date entry for gerrit.wikimedia.org in my /etc/hosts file.  =(,task_subcomment,Mea culpa -- my bug (in comment 2) was caused by an out-of-date entry for gerrit.wikimedia.org in my /etc/hosts file.  =(,BUG REPRODUCTION
242258,Commit missing from mediawiki/exentions/MassMessage repo,"(In reply to comment #2)
> This breakage seems to be a side-effect of the gerrit migration.  For me,
> 
> $ git clone
> https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor
> $ cd VisualEditor ; git log --oneline -1
> feff1fb Merge ""Improve welcome dialog support for large fonts""
> 
I can't reproduce. I get
47545a5 Remove no-insertion metadata corner case from `ve.dm.Transaction.pushReplace()`.

as expected.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
I can't reproduce. I get
47545a5 Remove no-insertion metadata corner case from CODE.

as expected.",SOLUTION DISCUSSION
242248,Commit missing from mediawiki/exentions/MassMessage repo,"This breakage seems to be a side-effect of the gerrit migration.  For me,

$ git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/VisualEditor
$ cd VisualEditor ; git log --oneline -1
feff1fb Merge ""Improve welcome dialog support for large fonts""

versus

$ git clone https://git.wikimedia.org/git/mediawiki/extensions/VisualEditor.git
$ cd VisualEditor ; git log --oneline -1
47545a5 Remove no-insertion metadata corner case from `ve.dm.Transaction.pushReplace()`


Note that https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FVisualEditor shows the latter commit, but 'git review -s ; git log gerrit/master' shows the former.",task_subcomment,"This breakage seems to be a side-effect of the gerrit migration.  For me,

$ git clone URL
$ cd VisualEditor ; git log --oneline -1
feff1fb Merge ""Improve welcome dialog support for large fonts""

versus

$ git clone URL
$ cd VisualEditor ; git log --oneline -1
47545a5 Remove no-insertion metadata corner case from CODE


Note that URL shows the latter commit, but 'git review -s ; git log gerrit/master' shows the former.",BUG REPRODUCTION
242238,Commit missing from mediawiki/exentions/MassMessage repo,"Eventhough the WebUI shows the change as having status 'Merged', the
change cannot be fetched directly:

  git fetch ssh://qchris@gerrit.wikimedia.org:29418/mediawiki/extensions/MassMessage refs/changes/96/82796/1
  fatal: Couldn't find remote ref refs/changes/96/82796/1",task_subcomment,"Eventhough the WebUI shows the change as having status 'Merged', the
change cannot be fetched directly:

  git fetch ssh://qchris@gerrit.wikimedia.org:29418/mediawiki/extensions/MassMessage refs/changes/96/82796/1
  fatal: Couldn't find remote ref refs/changes/96/82796/1",BUG REPRODUCTION
55788,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"*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",task_description,"*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
URL

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",BUG REPRODUCTION
239892,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!",task_subcomment,"Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!",SOLUTION USAGE
239884,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"(In reply to comment #4)

*This Test phase seems to have fixed problem on mediawiki.Tested at my user page on mediawiki at https://www.mediawiki.org/wiki/User:Mahitgar now works well


*Still to be fixed on rest of the wikis including mr wikipedia   https://mr.wikipedia.org/wiki/अभिमन्यु

Thanks and Regards

-Mahitgar",task_subcomment,"(In reply to comment #4)

*This Test phase seems to have fixed problem on mediawiki.Tested at my user page on mediawiki at URL now works well


*Still to be fixed on rest of the wikis including mr wikipedia   URL

Thanks and Regards

-Mahitgar",SOLUTION USAGE
239880,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!",task_subcomment,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

URL

Please let us know whether it fixes the bug!",SOLUTION USAGE
239873,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"(In reply to comment #2)

Firefox version- 23.0.1 It gets automatically updated

Rgds",task_subcomment,"(In reply to comment #2)

Firefox version- 23.0.1 It gets automatically updated

Rgds",ACTION ON ISSUE
239865,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"(In reply to comment #0)
> *Tested Browser and OS =Firefox+Win7

Please always provide exact version info (your Firefox version).",task_subcomment,"(In reply to comment #0)
QUOTE

Please always provide exact version info (your Firefox version).",ACTION ON ISSUE
239859,VisualEditor: Marathi/Devanagari: Save button does not get enabled for same or lesser length change,"Sorry 
*7 Save button does not get enabled",task_subcomment,"Sorry 
*7 Save button does not get enabled",BUG REPRODUCTION
55784,[EPIC] Use Parsoid HTML for all page views,"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.",task_description,"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.

URL 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.",FUTURE PLAN
2143205,[EPIC] Use Parsoid HTML for all page views,"I'm removing #user-notice, as this task is too global. Specific tasks, with concrete actions, are more than welcome to be tagged for user announcements. ",task_subcomment,"I'm removing #user-notice, as this task is too global. Specific tasks, with concrete actions, are more than welcome to be tagged for user announcements. ",ACTION ON ISSUE
2110328,[EPIC] Use Parsoid HTML for all page views,"Change 910556 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[operations/mediawiki-config@master] Turn on experimental Parsoid Read Views support, except on commons & wikidata%%%
https://gerrit.wikimedia.org/r/910556",task_subcomment,"Change 910556 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[operations/mediawiki-config@master] Turn on experimental Parsoid Read Views support, except on commons & wikidata%%%
GERRIT_URL",TASK PROGRESS
2110327,[EPIC] Use Parsoid HTML for all page views,"Change 910044 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[mediawiki/services/parsoid@master] Experimenally enable Parsoid Read Views with ?useparsoid=1 query string%%%
https://gerrit.wikimedia.org/r/910044",task_subcomment,"Change 910044 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[mediawiki/services/parsoid@master] Experimenally enable Parsoid Read Views with ?useparsoid=1 query string%%%
GERRIT_URL",SOLUTION USAGE
1137547,[EPIC] Use Parsoid HTML for all page views,"This ultra-epic is the perfect example of a task appropriately in the category of ""general MediaWiki tasks"".",task_subcomment,"This ultra-epic is the perfect example of a task appropriately in the category of ""general MediaWiki tasks"".",ACTION ON ISSUE
1100468,[EPIC] Use Parsoid HTML for all page views,Tagging this for the Web and Infrastructure teams.,task_subcomment,Tagging this for the Web and Infrastructure teams.,ACTION ON ISSUE
593537,[EPIC] Use Parsoid HTML for all page views,"Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. **If the session in this task took place**, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to ""resolved"". **If this session did not take place**, change the task status to ""declined"". **If this task** itself has become a well-defined action which **is not finished yet**, drag and drop this task into the ""Work continues after Summit"" column on the project workboard. Thank you for your help!",task_subcomment,"Wikimedia Developer Summit 2016 ended two weeks ago. This task is still open. **If the session in this task took place**, please make sure 1) that the session Etherpad notes are linked from this task, 2) that followup tasks for any actions identified have been created and linked from this task, 3) to change the status of this task to ""resolved"". **If this session did not take place**, change the task status to ""declined"". **If this task** itself has become a well-defined action which **is not finished yet**, drag and drop this task into the ""Work continues after Summit"" column on the project workboard. Thank you for your help!",ACTION ON ISSUE
559176,[EPIC] Use Parsoid HTML for all page views,"Today is November 6, and this proposal is basically not on track. Unless the situation suddenly changes and/or @robla-wmf and the Architecture Committee really want to schedule it, it will be removed as a #Wikimedia-Developer-Summit-2016 proposal.",task_subcomment,"Today is November 6, and this proposal is basically not on track. Unless the situation suddenly changes and/orSCREEN_NAME-wmf and the Architecture Committee really want to schedule it, it will be removed as a #Wikimedia-Developer-Summit-2016 proposal.",ACTION ON ISSUE
554085,[EPIC] Use Parsoid HTML for all page views,"@mobrovac: if you really think this should happen, you should drive it rather than delegate it to #ArchCom.  @gwicke //might// volunteer to take this on, but I'm not going to speak for him.",task_subcomment,"SCREEN_NAME: if you really think this should happen, you should drive it rather than delegate it to #ArchCom. SCREEN_NAME //might// volunteer to take this on, but I'm not going to speak for him.",ACTION ON ISSUE
553686,[EPIC] Use Parsoid HTML for all page views,"@Qgil, the reason is that this requires a wide cross-org consensus (and later work), so I'd say the ArchCom should drive this one.",task_subcomment,"SCREEN_NAME, the reason is that this requires a wide cross-org consensus (and later work), so I'd say the ArchCom should drive this one.",ACTION ON ISSUE
553681,[EPIC] Use Parsoid HTML for all page views,"With so many blocking/blocked tasks, no specific Summit plans specified in the description, and no assignee, it is difficult to evaluate whether this Summit proposal is On Track with ongoing discussion. Can someone step in as driver of the discussion and confirm the interest in getting a slot in the Summit schedule, please?",task_subcomment,"With so many blocking/blocked tasks, no specific Summit plans specified in the description, and no assignee, it is difficult to evaluate whether this Summit proposal is On Track with ongoing discussion. Can someone step in as driver of the discussion and confirm the interest in getting a slot in the Summit schedule, please?",ACTION ON ISSUE
540638,[EPIC] Use Parsoid HTML for all page views,"Congratulations! This is one of the 52 proposals that made it through the first deadline of the #Wikimedia-Developer-Summit-2016  [[ https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Submissions_and_selection_process | selection process ]]. Please pay attention to the next one:  > By **6 Nov 2015**, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.",task_subcomment,"Congratulations! This is one of the 52 proposals that made it through the first deadline of the #Wikimedia-Developer-Summit-2016  [[ URL | selection process ]]. Please pay attention to the next one:  > By **6 Nov 2015**, all Summit proposals must have active discussions and a Summit plan documented in the description. Proposals not reaching this critical mass can continue at their own path out of the Summit.",FUTURE PLAN
536650,[EPIC] Use Parsoid HTML for all page views,"FWIW, I did get some informal agreement that using Parsoid HTML for ""Printable page"" views was a reasonable thing to deploy on wikitech, as a first step.  I may try to write a standalone extension to do this.",task_subcomment,"FWIW, I did get some informal agreement that using Parsoid HTML for ""Printable page"" views was a reasonable thing to deploy on wikitech, as a first step.  I may try to write a standalone extension to do this.",SOLUTION DISCUSSION
418980,[EPIC] Use Parsoid HTML for all page views,">>! In T55784#1047315, @GWicke wrote:
> @jdforrester-wmf, is this really high priority for you right now right now? Should we prioritize intermediate steps higher?

It's not a Q3 urgency for VisualEditor, no.",task_subcomment,"QUOTE
QUOTE

It's not a Q3 urgency for VisualEditor, no.",ACTION ON ISSUE
413586,[EPIC] Use Parsoid HTML for all page views,"@jdforrester-wmf, is this really high priority for you right now right now? Should we prioritize intermediate steps higher?",task_subcomment,"SCREEN_NAME-wmf, is this really high priority for you right now right now? Should we prioritize intermediate steps higher?",PRIORITY DISCUSSION
239691,[EPIC] Use Parsoid HTML for all page views,*** Bug 53780 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53780 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
55758,Visualditor: Marathi/Devanagari: edit change not reflecting in edit preview,"*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",task_description,"*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
URL

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",BUG REPRODUCTION
237966,Visualditor: Marathi/Devanagari: edit change not reflecting in edit preview,"Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!",task_subcomment,"Based on your comments, I'm marking this as FIXED - please check, and reopen if it's not!",SOLUTION USAGE
237960,Visualditor: Marathi/Devanagari: edit change not reflecting in edit preview,"*Done first round of testing seems to have solved but since problem is not frequent one for final confirmation we will need to have more tests and time.

Thanks and regards",task_subcomment,"*Done first round of testing seems to have solved but since problem is not frequent one for final confirmation we will need to have more tests and time.

Thanks and regards",TASK PROGRESS
237952,Visualditor: Marathi/Devanagari: edit change not reflecting in edit preview,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!",task_subcomment,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

URL

Please let us know whether it fixes the bug!",SOLUTION USAGE
237945,Visualditor: Marathi/Devanagari: edit change not reflecting in edit preview,Usually this problem does not come in isolation but comes when some other problems are happening reported in earlier bugs for Marathi/Devnagri but it is defficult to specify that the problem will come when exactly a specific other problem is existent.May need more observation to notify exact time of ocurrance.,task_subcomment,Usually this problem does not come in isolation but comes when some other problems are happening reported in earlier bugs for Marathi/Devnagri but it is defficult to specify that the problem will come when exactly a specific other problem is existent.May need more observation to notify exact time of ocurrance.,INVESTIGATION AND EXPLORATION
55757,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"*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",task_description,"*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 URL

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**:
URL",BUG REPRODUCTION
237895,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

GERRIT_URL",ACTION ON ISSUE
237888,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"Change 80689 had a related patch set uploaded by Divec:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 had a related patch set uploaded by Divec:
Revert model to use simple UTF-16 code units

GERRIT_URL",SOLUTION USAGE
237881,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"Hello,

Would it be possible to test this against current master? You can use this at
http://en.wikipedia.beta.wmflabs.org/ - we believe that we may have fixed the
issues (or, at least, changed the behaviour) since you tested it.

Thank you!",task_subcomment,"Hello,

Would it be possible to test this against current master? You can use this at
URL - we believe that we may have fixed the
issues (or, at least, changed the behaviour) since you tested it.

Thank you!",SOLUTION DISCUSSION
237873,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"(In reply to comment #1)

*Did one round of test at my user page on media wiki https://www.mediawiki.org/wiki/User:Mahitgar 

Seems to get partially fixed with some different wierdness in some other case so will need more tests and time to confirm


Rgds",task_subcomment,"(In reply to comment #1)

*Did one round of test at my user page on media wiki URL 

Seems to get partially fixed with some different wierdness in some other case so will need more tests and time to confirm


Rgds",BUG REPRODUCTION
237867,VisualEditor: Marathi/Devanagari: Backpace deletes  text on right side,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!",task_subcomment,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

URL

Please let us know whether it fixes the bug!",SOLUTION USAGE
55750,VisualEditor: Page down and page up not working as expected in Firefox,"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",task_description,"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**:
URL
URL",BUG REPRODUCTION
237423,VisualEditor: Page down and page up not working as expected in Firefox,"AFAICT this is now works in Firefox since the Firefox-related CE fixes, though there are some oddities generally about Page Up / Page Down. Closing as such for now, but happy to re-open if I've missed something.",task_subcomment,"AFAICT this is now works in Firefox since the Firefox-related CE fixes, though there are some oddities generally about Page Up / Page Down. Closing as such for now, but happy to re-open if I've missed something.",ACTION ON ISSUE
237419,VisualEditor: Page down and page up not working as expected in Firefox,"I am able to reproduce this on Firefox 24/Linux.
Page down on the following articles jumps to the bottom of the article, irrespective of where the cursor is placed.  Even stranger, page up also goes to the bottom of the article.
https://en.wikipedia.org/wiki/Nigeria?veaction=edit
https://en.wikipedia.org/wiki/Great_Balls_of_Fire?veaction=edit

The problematic behaviour doesnt happen on simpler articles like
https://en.wikipedia.org/w/index.php?title=Walter_T._Downing&veaction=edit
https://en.wikipedia.org/w/index.php?title=Sienno,_W%C4%85growiec_County&veaction=edit

Bug 51957 is another Firefox only keyboard navigation problem.",task_subcomment,"I am able to reproduce this on Firefox 24/Linux.
Page down on the following articles jumps to the bottom of the article, irrespective of where the cursor is placed.  Even stranger, page up also goes to the bottom of the article.
URL
URL

The problematic behaviour doesnt happen on simpler articles like
URL
URL

Bug 51957 is another Firefox only keyboard navigation problem.",BUG REPRODUCTION
237415,VisualEditor: Page down and page up not working as expected in Firefox,"Germanjoe comments suggests it may be related to problems establishing cursor position relative to templates:

""Maybe a related error occured, while testing in [[Nigeria]], Firefox 23, mono. Enter VE-mode and click below one of the huge (really huge) navbox farms at the end of the article (in the blank line below them). Now i made two tests:

Click ""Page up"" => OK, scrolls up as expected. 
Now click ""Page up"" again => ERROR, jumps down to the initial position below the navbox.
        
another test from the same initial position below the huge navbox: 
""Page up"", then ""Page down"", then ""Page up"" and a second ""Page up"" => works OK.

If i had to guess (uneducated as always), it looks like VE has problems storing or establishing the cursor position while scrolling through some huge or complex templates. """,task_subcomment,"Germanjoe comments suggests it may be related to problems establishing cursor position relative to templates:

""Maybe a related error occured, while testing in [[Nigeria]], Firefox 23, mono. Enter VE-mode and click below one of the huge (really huge) navbox farms at the end of the article (in the blank line below them). Now i made two tests:

Click ""Page up"" => OK, scrolls up as expected. 
Now click ""Page up"" again => ERROR, jumps down to the initial position below the navbox.
        
another test from the same initial position below the huge navbox: 
""Page up"", then ""Page down"", then ""Page up"" and a second ""Page up"" => works OK.

If i had to guess (uneducated as always), it looks like VE has problems storing or establishing the cursor position while scrolling through some huge or complex templates. """,BUG REPRODUCTION
237409,VisualEditor: Page down and page up not working as expected in Firefox,"It's Windows 7, sorry. I am also the original reporter of the related bug 52445, whose effect is also being kicked to the end of the edit box and Firefox only.",task_subcomment,"It's Windows 7, sorry. I am also the original reporter of the related bug 52445, whose effect is also being kicked to the end of the edit box and Firefox only.",BUG REPRODUCTION
237402,VisualEditor: Page down and page up not working as expected in Firefox,the same IP user has followed up saying (while I was reporting this) that they have been unable to reproduce their original report in Firefox 23.0.1 in Windows (they don't say which version),task_subcomment,the same IP user has followed up saying (while I was reporting this) that they have been unable to reproduce their original report in Firefox 23.0.1 in Windows (they don't say which version),BUG REPRODUCTION
55712,run VE browser tests in vagrant,"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",task_description,"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",SOLUTION DISCUSSION
234968,run VE browser tests in vagrant,Closing since this looks like it has been fixed to me. Please reopen if needed.,task_subcomment,Closing since this looks like it has been fixed to me. Please reopen if needed.,ACTION ON ISSUE
234963,run VE browser tests in vagrant,"**jhall** wrote:

I was able to get this working on my MacBook Air with the following workflow (I have not been able to verify that this works on platforms other than Mac OS):

1. vagrant enable-role visualeditor
2. vagrant up
3. vagrant provision
4. vagrant ssh -- -X
5. cd /srv/VisualEditor/VisualEditor/modules/ve-mw/test/browser
6. export MEDIAWIKI_URL=
7. export MEDIAWIKI_USER=
8. export MEDIAWIKI_PASSWORD=
9. export PATH=$PATH:/home/vagrant/.gem/ruby/1.9.1/gems/cucumber-1.3.8/bin 
10. bundle exec cucumber ",task_subcomment,"**jhall** wrote:

I was able to get this working on my MacBook Air with the following workflow (I have not been able to verify that this works on platforms other than Mac OS):

1. vagrant enable-role visualeditor
2. vagrant up
3. vagrant provision
4. vagrant ssh -- -X
5. cd /srv/VisualEditor/VisualEditor/modules/ve-mw/test/browser
6. export MEDIAWIKI_URL=
7. export MEDIAWIKI_USER=
8. export MEDIAWIKI_PASSWORD=
9. export PATH=$PATH:/home/vagrant/.gem/ruby/1.9.1/gems/cucumber-1.3.8/bin 
10. bundle exec cucumber ",SOLUTION DISCUSSION
55691,browsertests: triggers for VisualEditor,"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",task_description,"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**:
URL
URL",FUTURE PLAN
233751,browsertests: triggers for VisualEditor,"**jhall** wrote:

Basic test is merged and in place, so marking this bug resolved.",task_subcomment,"**jhall** wrote:

Basic test is merged and in place, so marking this bug resolved.",ACTION ON ISSUE
233747,browsertests: triggers for VisualEditor,"Change 111890 merged by jenkins-bot:
[Browser test] Headless browser test(s)

https://gerrit.wikimedia.org/r/111890",task_subcomment,"Change 111890 merged by jenkins-bot:
[Browser test] Headless browser test(s)

GERRIT_URL",ACTION ON ISSUE
233741,browsertests: triggers for VisualEditor,"Change 100797 abandoned by Hashar:
[browser test] Cucumber default profile for CI

Reason:
we are using something different than the ciwmf profile.

https://gerrit.wikimedia.org/r/100797",task_subcomment,"Change 100797 abandoned by Hashar:
[browser test] Cucumber default profile for CI

Reason:
we are using something different than the ciwmf profile.

GERRIT_URL",ACTION ON ISSUE
233734,browsertests: triggers for VisualEditor,"Change 111890 had a related patch set uploaded by Jhall:
[Browser test] New test for headless browser testing on a fresh Mediawiki install with VisualEditor.

https://gerrit.wikimedia.org/r/111890",task_subcomment,"Change 111890 had a related patch set uploaded by Jhall:
[Browser test] New test for headless browser testing on a fresh Mediawiki install with VisualEditor.

GERRIT_URL",TASK PROGRESS
233729,browsertests: triggers for VisualEditor,"Change 110468 abandoned by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

Reason:
Abandoning this change since I'm going to start fresh with a slightly different approach.

https://gerrit.wikimedia.org/r/110468",task_subcomment,"Change 110468 abandoned by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

Reason:
Abandoning this change since I'm going to start fresh with a slightly different approach.

GERRIT_URL",TASK PROGRESS
233725,browsertests: triggers for VisualEditor,"Change 110468 had a related patch set uploaded by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

https://gerrit.wikimedia.org/r/110468",task_subcomment,"Change 110468 had a related patch set uploaded by Jhall:
[Browser test] WIP Headless test for VE verification on a fresh Mediawiki install (as on Integration server).

GERRIT_URL",TASK PROGRESS
233718,browsertests: triggers for VisualEditor,"Change 102960 abandoned by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

Reason:
Abandoning this patch since we have implemented support for headless browser testing in the mediawiki-selenium Rubygem (rather than implementing it in each individual repo).

https://gerrit.wikimedia.org/r/102960",task_subcomment,"Change 102960 abandoned by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

Reason:
Abandoning this patch since we have implemented support for headless browser testing in the mediawiki-selenium Rubygem (rather than implementing it in each individual repo).

GERRIT_URL",ACTION ON ISSUE
233714,browsertests: triggers for VisualEditor,"**jhall** wrote:

After some further investigation, we've decided to use the ""headless"" Rubygem for headless browser testing, and we've decided to incorporate that support into the mediawiki-selenium Rubygem so that it will be available to all WMF repositories that have browser tests.  The task for updating the mediawiki-selenium is captured in Bugzilla 60584.",task_subcomment,"**jhall** wrote:

After some further investigation, we've decided to use the ""headless"" Rubygem for headless browser testing, and we've decided to incorporate that support into the mediawiki-selenium Rubygem so that it will be available to all WMF repositories that have browser tests.  The task for updating the mediawiki-selenium is captured in Bugzilla 60584.",SOLUTION DISCUSSION
233709,browsertests: triggers for VisualEditor,"**jhall** wrote:

Scripts used to evaluate PhantomJS ""bind"" injection

After a pairing session with Željko, I went back to basics and tried to get Function.prototype.bind injection working directly with PhantomJS (ignoring the rest of our test infrastructure for the time being).  

Per the attached scripts, I tried all of the relevant methods noted in the PhantomJS API documentation:

http://phantomjs.org/api/webpage/

...and still no luck.  The Main_Page loads fine, with the exception of the VE editing link/tab, which is available to other browsers (Chrome, Firefox, etc) at the same URL.

Per a suggestion from Antoine, it might be time to investigate using Firefox in a headless mode as a potential substitute for PhantomJS.

**Attached**: {F11112}",task_subcomment,"**jhall** wrote:

Scripts used to evaluate PhantomJS ""bind"" injection

After a pairing session with Željko, I went back to basics and tried to get Function.prototype.bind injection working directly with PhantomJS (ignoring the rest of our test infrastructure for the time being).  

Per the attached scripts, I tried all of the relevant methods noted in the PhantomJS API documentation:

URL

...and still no luck.  The Main_Page loads fine, with the exception of the VE editing link/tab, which is available to other browsers (Chrome, Firefox, etc) at the same URL.

Per a suggestion from Antoine, it might be time to investigate using Firefox in a headless mode as a potential substitute for PhantomJS.

**Attached**: {F11112}",SOLUTION DISCUSSION
233703,browsertests: triggers for VisualEditor,"**jhall** wrote:

Changing bug status since task in still WIP.",task_subcomment,"**jhall** wrote:

Changing bug status since task in still WIP.",ACTION ON ISSUE
233697,browsertests: triggers for VisualEditor,"Change 102960 had a related patch set uploaded by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

https://gerrit.wikimedia.org/r/102960",task_subcomment,"Change 102960 had a related patch set uploaded by Jhall:
[Browser test] WIP Modifications for PhantomJS compatibility

GERRIT_URL",TASK PROGRESS
233690,browsertests: triggers for VisualEditor,"**jhall** wrote:

Timo pointed me in the right direction:


jeffrey-hall:browser jeffreyhall$ phantomjs
phantomjs> Function.prototype.bind
undefined


Turns out PhantomJS is built with an old version of JavaScriptCore that is missing the ""bind"" implementation, which is needed to satisfy Visual Editor's es5 features check: 

https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/cf7f2b141d/modules/ve-mw/init/targets/ve.init.mw.ViewPageTarget.init.js#L72-L84

…but a workaround is available:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind?redirectlocale=en-US&redirectslug=JavaScript%2FReference%2FGlobal_Objects%2FFunction%2Fbind#Compatibility

…so I'll investigate the workaround next.",task_subcomment,"**jhall** wrote:

Timo pointed me in the right direction:


jeffrey-hall:browser jeffreyhall$ phantomjs
phantomjs> Function.prototype.bind
undefined


Turns out PhantomJS is built with an old version of JavaScriptCore that is missing the ""bind"" implementation, which is needed to satisfy Visual Editor's es5 features check: 

URL

…but a workaround is available:

URL

…so I'll investigate the workaround next.",SOLUTION DISCUSSION
233682,browsertests: triggers for VisualEditor,"Created attachment 14138
ve phantomjs

**Attached**: {F11111}",task_subcomment,"Created attachment 14138
ve phantomjs

**Attached**: {F11111}",ACTION ON ISSUE
233676,browsertests: triggers for VisualEditor,"Created attachment 14137
ve ff

**Attached**: {F11109}",task_subcomment,"Created attachment 14137
ve ff

**Attached**: {F11109}",ACTION ON ISSUE
233668,browsertests: triggers for VisualEditor,"Strange. I am pretty sure PhantomJS has JS. :)

But, this simple script takes screen shot that shows it can not load visual editor.

require ""watir-webdriver""
browser = Watir::Browser.new :phantomjs
browser.goto ""https://test2.wikipedia.org/wiki/User:Zeljko.filipin%28WMF%29?veaction=edit&vewhitelist=1""
browser.window.resize_to 1280, 1024
browser.screenshot.save ""ve.png""

If :phantomjs is replaced with :firefox, then visual editor opens just fine (see screen shots).",task_subcomment,"Strange. I am pretty sure PhantomJS has JS. :)

But, this simple script takes screen shot that shows it can not load visual editor.

require ""watir-webdriver""
browser = Watir::Browser.new :phantomjs
browser.goto ""URL
browser.window.resize_to 1280, 1024
browser.screenshot.save ""ve.png""

If :phantomjs is replaced with :firefox, then visual editor opens just fine (see screen shots).",BUG REPRODUCTION
233661,browsertests: triggers for VisualEditor,"If a browser is not on the blacklist, and meets the functionality criteria, then the edit tabs for VisualEditor should show up. A browser not being on the whitelist just means the user gets a warning when they edit. Adding PhantomJS to the whitelist will not make VisualEditor appear if it doesn't already.

(Also, you can bypass the blacklist with ?veaction=edit&vewhitelist=1 which should trigger VE even if you don't have a functional browser, as long as it has JS.)",task_subcomment,"If a browser is not on the blacklist, and meets the functionality criteria, then the edit tabs for VisualEditor should show up. A browser not being on the whitelist just means the user gets a warning when they edit. Adding PhantomJS to the whitelist will not make VisualEditor appear if it doesn't already.

(Also, you can bypass the blacklist with ?veaction=edit&vewhitelist=1 which should trigger VE even if you don't have a functional browser, as long as it has JS.)",SOLUTION DISCUSSION
233656,browsertests: triggers for VisualEditor,"**jhall** wrote:

Ah, I believe Željko is correct - looks like VE has a whitelist in addition to a blacklist.  See section beginning on line 169 in this file:

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/1cd761dad8aed132619c2897abe367404ca8f3ca/modules%2Fve-mw%2Finit%2Ftargets%2Fve.init.mw.ViewPageTarget.js

Will talk to the VE dev team and see if we can get PhantomJS whitelisted.",task_subcomment,"**jhall** wrote:

Ah, I believe Željko is correct - looks like VE has a whitelist in addition to a blacklist.  See section beginning on line 169 in this file:

URL

Will talk to the VE dev team and see if we can get PhantomJS whitelisted.",SOLUTION DISCUSSION
233653,browsertests: triggers for VisualEditor,"Created attachment 14130
phantomjs screen shot

**Attached**: {F11108}",task_subcomment,"Created attachment 14130
phantomjs screen shot

**Attached**: {F11108}",ATTACHMENT
233651,browsertests: triggers for VisualEditor,Looks like phantomjs is blacklisted (or not whitelisted). There is no visual editor edit option (see screen shot).,task_subcomment,Looks like phantomjs is blacklisted (or not whitelisted). There is no visual editor edit option (see screen shot).,BUG REPRODUCTION
233649,browsertests: triggers for VisualEditor,"**jhall** wrote:

Looks like it's not a problem with PhantomJS being blacklisted, per the VisualEditor browser blacklist which begins at line 890 of this file:

https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FVisualEditor/b922592902ad57f770b6810566b820aada74aa47/VisualEditor.php

…so I'll spend some more time tomorrow to see if I can figure out why PhantomJS doesn't seem to work as intended even when navigating directly to an ""editing mode"" URL.",task_subcomment,"**jhall** wrote:

Looks like it's not a problem with PhantomJS being blacklisted, per the VisualEditor browser blacklist which begins at line 890 of this file:

URL

…so I'll spend some more time tomorrow to see if I can figure out why PhantomJS doesn't seem to work as intended even when navigating directly to an ""editing mode"" URL.",INVESTIGATION AND EXPLORATION
233646,browsertests: triggers for VisualEditor,"Could it be that phantomjs lack some javascript functionality that would cause VisualEditor to disable itself ?  Might be a browser whitelist as well.  Honestly, I have no clue how it is handled in VisualEditor.",task_subcomment,"Could it be that phantomjs lack some javascript functionality that would cause VisualEditor to disable itself ?  Might be a browser whitelist as well.  Honestly, I have no clue how it is handled in VisualEditor.",SOLUTION DISCUSSION
233642,browsertests: triggers for VisualEditor,"**jhall** wrote:

PhantomJS screenshot from VE editing mode URL

Thanks Željko.  I tried modifying the ""anon.feature"" test to navigate directly to the Visual Editor editing URL (?veaction=edit), but from capturing both a screenshot (attached) and the raw HTML that PhantomJS lands on, it does not appear that PhantomJS is successfully entering into Visual Editor editing mode.

In any case, we're getting closer step-by-step, so I'll continue to work on this.

**Attached**: {F11106}",task_subcomment,"**jhall** wrote:

PhantomJS screenshot from VE editing mode URL

Thanks Željko.  I tried modifying the ""anon.feature"" test to navigate directly to the Visual Editor editing URL (?veaction=edit), but from capturing both a screenshot (attached) and the raw HTML that PhantomJS lands on, it does not appear that PhantomJS is successfully entering into Visual Editor editing mode.

In any case, we're getting closer step-by-step, so I'll continue to work on this.

**Attached**: {F11106}",ACTION ON ISSUE
233638,browsertests: triggers for VisualEditor,"Created attachment 14080
phantomjs screen shot

**Attached**: {F11105}",task_subcomment,"Created attachment 14080
phantomjs screen shot

**Attached**: {F11105}",ATTACHMENT
233633,browsertests: triggers for VisualEditor,"(In reply to comment #6)
> The test case currently does not work with PhantomJS, so I'll spend more time
> tomorrow trying to figure out why PhantomJS can't click into Visual Editor
> editing mode.

In phantomjs, ""edit"" link is not visible by default, see attached screen shot.",task_subcomment,"(In reply to comment #6)
QUOTE
QUOTE
QUOTE

In phantomjs, ""edit"" link is not visible by default, see attached screen shot.",BUG REPRODUCTION
233628,browsertests: triggers for VisualEditor,"**jhall** wrote:

I went ahead and amended the existing Gerrit ID:

https://gerrit.wikimedia.org/r/#/c/100797/

…with an additional anon test case that edits a random page (which will likely always be the ""Main Page"" for a fresh wiki install).  

The test case currently does not work with PhantomJS, so I'll spend more time tomorrow trying to figure out why PhantomJS can't click into Visual Editor editing mode.",task_subcomment,"**jhall** wrote:

I went ahead and amended the existing Gerrit ID:

URL

…with an additional anon test case that edits a random page (which will likely always be the ""Main Page"" for a fresh wiki install).  

The test case currently does not work with PhantomJS, so I'll spend more time tomorrow trying to figure out why PhantomJS can't click into Visual Editor editing mode.",SOLUTION DISCUSSION
233622,browsertests: triggers for VisualEditor,"Jeff : sure, if you can get a test that roughly does:

 - anonymous user
 - go to main page
 - press Edit (visual editor version)
 - ensure visual editor is loaded

That would be a nice first step that would validate the Jenkins job and VE/Parsoid is properly setup :-)",task_subcomment,"Jeff : sure, if you can get a test that roughly does:

 - anonymous user
 - go to main page
 - press Edit (visual editor version)
 - ensure visual editor is loaded

That would be a nice first step that would validate the Jenkins job and VE/Parsoid is properly setup :-)",TASK PROGRESS
233614,browsertests: triggers for VisualEditor,"**jhall** wrote:

Sorry I wasn't able to get to work on this bug quickly Antoine - let me know if you want me to work on creating a new browser test that will succeed in this scenario (the existing anon test will fail since it presumes the existence of a User page in the target wiki).",task_subcomment,"**jhall** wrote:

Sorry I wasn't able to get to work on this bug quickly Antoine - let me know if you want me to work on creating a new browser test that will succeed in this scenario (the existing anon test will fail since it presumes the existence of a User page in the target wiki).",TASK PROGRESS
233607,browsertests: triggers for VisualEditor,"And I manage to get VisualEditor + Parsoid to be setup automatically using Jenkins. The related job configuration is pending in https://gerrit.wikimedia.org/r/#/c/100800/ (need to be polished).

I confirmed the wiki is functional and managed to edit a page using VE \O/

Next steps:
* cleanup the job configuration
* make the wiki faster (sqlite is not on tmpfs as an example)
* try to get at least ONE browser test scenario to pass (anon ones are good candidates apparently)",task_subcomment,"And I manage to get VisualEditor + Parsoid to be setup automatically using Jenkins. The related job configuration is pending in URL (need to be polished).

I confirmed the wiki is functional and managed to edit a page using VE \O/

Next steps:
* cleanup the job configuration
* make the wiki faster (sqlite is not on tmpfs as an example)
* try to get at least ONE browser test scenario to pass (anon ones are good candidates apparently)",SOLUTION USAGE
233601,browsertests: triggers for VisualEditor,"Change 100797 had a related patch set uploaded by Hashar:
[browser test] cucumber default profile for CI

https://gerrit.wikimedia.org/r/100797",task_subcomment,"Change 100797 had a related patch set uploaded by Hashar:
[browser test] cucumber default profile for CI

GERRIT_URL",TASK PROGRESS
233597,browsertests: triggers for VisualEditor,"**jhall** wrote:

Assigning to myself per an e-mail thread with Antoine, Chris, and Željko.",task_subcomment,"**jhall** wrote:

Assigning to myself per an e-mail thread with Antoine, Chris, and Željko.",ACTION ON ISSUE
55679,VisualEditor: Selection-expansion doesn't trigger for Thai script text,"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",task_description,"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",BUG REPRODUCTION
257335,VisualEditor: Selection-expansion doesn't trigger for Thai script text,"This is not a ""bug"" per se - VisualEditor's word boundary detection only works for scripts that use word boundaries. Consequently it doesn't operate on Chinese or Thai (which don't use word boundaries), but does for Korean, Latin and Cyrillic languages, and others (which do).

Theoretically it would be possible to build some code for applying algorithmic word boundary rules for Thai, but that's both complex and slow, so if that is desired it should be opened as an enhancement (and we'd need to see how we can make it only slow down users who are editing in Thai).

Marking as INVALID.",task_subcomment,"This is not a ""bug"" per se - VisualEditor's word boundary detection only works for scripts that use word boundaries. Consequently it doesn't operate on Chinese or Thai (which don't use word boundaries), but does for Korean, Latin and Cyrillic languages, and others (which do).

Theoretically it would be possible to build some code for applying algorithmic word boundary rules for Thai, but that's both complex and slow, so if that is desired it should be opened as an enhancement (and we'd need to see how we can make it only slow down users who are editing in Thai).

Marking as INVALID.",ACTION ON ISSUE
257331,VisualEditor: Selection-expansion doesn't trigger for Thai script text,"I tested with Telugu and Malayalam, and this doesn't happen there. Must be something special with Thai.",task_subcomment,"I tested with Telugu and Malayalam, and this doesn't happen there. Must be something special with Thai.",BUG REPRODUCTION
257325,VisualEditor: Selection-expansion doesn't trigger for Thai script text,"Confirmed in Thai Wikipedia and in the English Wikipedia with Thai words.

Furthermore, if you Ctrl-K on a Latin word and then Ctrl-K on a Thai word, the Latin word appears in the input box. See this test case:
https://en.wikipedia.org/wiki/User:Amire80/VE-Thai",task_subcomment,"Confirmed in Thai Wikipedia and in the English Wikipedia with Thai words.

Furthermore, if you Ctrl-K on a Latin word and then Ctrl-K on a Thai word, the Latin word appears in the input box. See this test case:
URL",SOLUTION DISCUSSION
55642,VisualEditor: Removing formatting from part of a link causes a snowman,"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",task_description,"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",BUG REPRODUCTION
255039,VisualEditor: Removing formatting from part of a link causes a snowman,This was fixed two weeks ago; sorry for the slowness in replying.,task_subcomment,This was fixed two weeks ago; sorry for the slowness in replying.,ACTION ON ISSUE
55560,"VisualEditor: After adding a link, cursor appears before rather than after the new insertion","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",task_description,"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",BUG REPRODUCTION
249995,"VisualEditor: After adding a link, cursor appears before rather than after the new insertion","Change 81872 merged by jenkins-bot:
Cursor fix after link insertion

https://gerrit.wikimedia.org/r/81872",task_subcomment,"Change 81872 merged by jenkins-bot:
Cursor fix after link insertion

GERRIT_URL",ACTION ON ISSUE
249994,"VisualEditor: After adding a link, cursor appears before rather than after the new insertion","Change 81872 had a related patch set uploaded by Jforrester:
Cursor fix after link insertion

https://gerrit.wikimedia.org/r/81872",task_subcomment,"Change 81872 had a related patch set uploaded by Jforrester:
Cursor fix after link insertion

GERRIT_URL",ACTION ON ISSUE
249991,"VisualEditor: After adding a link, cursor appears before rather than after the new insertion","This was actually not just for RTL wikis, and the submitted patch fixes the problem for both directions in Annotation Inspector (for both links and languages)",task_subcomment,"This was actually not just for RTL wikis, and the submitted patch fixes the problem for both directions in Annotation Inspector (for both links and languages)",SOLUTION DISCUSSION
55543,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,"**Author:** `wojciech.r`

**Description:**
When I edit existing content in  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",task_description,"**Author:** CODE

**Description:**
When I edit existing content in  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.

URL

--------------------------
**Version**: unspecified
**Severity**: major",BUG REPRODUCTION
249251,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,"This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September. Sorry for the disruption.",task_subcomment,"This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September. Sorry for the disruption.",SOLUTION USAGE
249244,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,"Change 82063 merged by jenkins-bot:
Round trip alien extensions correctly when edited

https://gerrit.wikimedia.org/r/82063",task_subcomment,"Change 82063 merged by jenkins-bot:
Round trip alien extensions correctly when edited

GERRIT_URL",ACTION ON ISSUE
249239,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,This fix preserves attributes correctly. The above bug would allow you to edit them.,task_subcomment,This fix preserves attributes correctly. The above bug would allow you to edit them.,SOLUTION DISCUSSION
249235,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,Related bug 53614,task_subcomment,Related bug 53614,ACTION ON ISSUE
249231,VisualEditor: Editing a  block with the experimental generic editor leads to brokenness because the attributes get blanked,"Change 82063 had a related patch set uploaded by Esanders:
Round trip alien extensions correctly when edited

https://gerrit.wikimedia.org/r/82063",task_subcomment,"Change 82063 had a related patch set uploaded by Esanders:
Round trip alien extensions correctly when edited

GERRIT_URL",ACTION ON ISSUE
55507,VisualEditor: Pressing up while next to an inline image throws an exception,"

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
246922,VisualEditor: Pressing up while next to an inline image throws an exception,"Change 81596 merged by jenkins-bot:
Move contentEditable=false to protected node

https://gerrit.wikimedia.org/r/81596",task_subcomment,"Change 81596 merged by jenkins-bot:
Move contentEditable=false to protected node

GERRIT_URL",ACTION ON ISSUE
246919,VisualEditor: Pressing up while next to an inline image throws an exception,"Change 81596 had a related patch set uploaded by Esanders:
Move contentEditable=false to protected node

https://gerrit.wikimedia.org/r/81596",task_subcomment,"Change 81596 had a related patch set uploaded by Esanders:
Move contentEditable=false to protected node

GERRIT_URL",ACTION ON ISSUE
55477,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","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",task_description,"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:
URL

Example course page:
URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
244684,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote:

P.S. Go to a production wiki and try this in a js console:

mw.config.get('wgContentNamespaces')

The results coincide:

https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L9292-9349

I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",task_subcomment,"**andrew.green.df** wrote:

P.S. Go to a production wiki and try this in a js console:

mw.config.get('wgContentNamespaces')

The results coincide:

URL

I lost the scent of $wgVisualEditorNamespaces following a brief pursuit, though...",SOLUTION DISCUSSION
244678,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote:

Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",task_subcomment,"**andrew.green.df** wrote:

Added a comment on the Gerrit change. tl;dr: Is $wgContentNamespaces getting checked? I don't see how EP_NS could be there, and checking it in js seems to fix the issue. Thanks!",SOLUTION DISCUSSION
244674,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Change 125233 merged by jenkins-bot:
Don't change tabs on Education Program pages

https://gerrit.wikimedia.org/r/125233",task_subcomment,"Change 125233 merged by jenkins-bot:
Don't change tabs on Education Program pages

GERRIT_URL",ACTION ON ISSUE
244670,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Andrew Green from comment #9)
> I can look into making the EP extension warn VE through some generic
> mechanism.

Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-)


> BTW, I wouldn't recommend that anyone try to make major changes to the EP
> extension, as the plan is just to rewrite it.

Understood. 


> Alex's patch also looks like a fine temporary solution. :)

Alex's patch is necessarily a horrible hack, but yeah…",task_subcomment,"(In reply to Andrew Green from comment #9)
QUOTE
QUOTE

Ideally EP would warn VE through the existing generic mechanisms that Krinkle suggested; this would avoid VE having to have EP-specific code in it entirely. :-)


QUOTE
QUOTE

Understood. 


QUOTE

Alex's patch is necessarily a horrible hack, but yeah…",SOLUTION DISCUSSION
244666,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","**andrew.green.df** wrote:

I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes.

BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it.

The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",task_subcomment,"**andrew.green.df** wrote:

I can look into making the EP extension warn VE through some generic mechanism. The bug is moderately important for users of the extension, and I imagine there's some way to do this without making major changes.

BTW, I wouldn't recommend that anyone try to make major changes to the EP extension, as the plan is just to rewrite it.

The issues Krinkle mentions are certainly valid. Alex's patch also looks like a fine temporary solution. :)",SOLUTION DISCUSSION
244665,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","(In reply to Krinkle from comment #7)
> I'd say EP should either let us know how to generically detect it without
> being EP specific, or it should implement support to at least do one thing
> right. Possibly we could do the latter ourselves (maybe Alex is interested
> in patching EP).

I don't really think this bug is important enough to VE to justify making big changes to how another extension works...",task_subcomment,"(In reply to Krinkle from comment #7)
QUOTE
QUOTE
QUOTE
QUOTE

I don't really think this bug is important enough to VE to justify making big changes to how another extension works...",SOLUTION DISCUSSION
244661,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.

Not one of them is being used by EP right now.

* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page).

* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id.

* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because:
  1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=).
  2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected.
  3) Existence check impossible.  Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.

There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them.

I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",task_subcomment,"From a quick investigation it looks like there are about a dozen different ways in which VisualEditor can reasonably find out that the page is not a real wikipage.

Not one of them is being used by EP right now.

* It's pretending to be a wiki page (by having its own namespace and using action=view, albeit overridden, to render the dynamically constructed page).

* Generally this is something we have Special pages for. If the rendering is completely taken over (as in, there is no page table entry, no revisions table entries etc.), it should be a Special page. Or at least a custom namespace with a negative namespace id.

* It abuses existing WikiPage action queries (action=edit, action=delete), which doesn't make sense because it isn't a WikiPage. So inherently this is going to cause trouble because:
  1) They aren't compatible (the query string parameters Action pages take aren't supported, other than title=).
  2) It doesn't scale. Right now they take over move, delete, edit and view. But there are more page actions, and by design they will not support all of them (they override the ones they re-implement and the rest just fails). For example ""View history"" (action=history) is quite useless right now. And action=edit doesn't work as expected. Not to mention API actions, none of those are working as expected.
  3) Existence check impossible.  Because they aren't actually wiki pages with page and revision ids, existence check isn't possible. ContentModel can't be overridden because it doesn't use wikipage content. All pages are considered inexistent pages in a custom namespace, and then overridden to exist in some cases.

There are many different ways in which EP could indicate in a standard / reliable way that doesn't require other code to hardcode for EP specifically, and it doesn't seem to be using any of them.

I'd say EP should either let us know how to generically detect it without being EP specific, or it should implement support to at least do one thing right. Possibly we could do the latter ourselves (maybe Alex is interested in patching EP).",SOLUTION DISCUSSION
244658,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Change 125233 had a related patch set uploaded by Alex Monk:
Only make tab changes on articles

https://gerrit.wikimedia.org/r/125233",task_subcomment,"Change 125233 had a related patch set uploaded by Alex Monk:
Only make tab changes on articles

GERRIT_URL",ACTION ON ISSUE
244655,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages",I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).,task_subcomment,I think VE shouldn't be modifying tabs on pages which aren't articles (check wgIsArticle is true before doing anything).,SOLUTION DISCUSSION
244651,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?",task_subcomment,"Slinging to Alex – not sure what the fix here would be (it feels like overriding the semantics of a tab is something that should involve a class change, really) – thoughts?",SOLUTION DISCUSSION
244643,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",task_subcomment,"Hi James, just noting for the record that this is still quite problematic, and we very much appreciate any efforts to fix it. :)",ACTION ON ISSUE
244637,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages",*** Bug 56844 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 56844 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
244633,"VisualEditor: Edit tab replaced with ""Create source"" for Education Program pages","@James: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",task_subcomment,"SCREEN_NAME: Any chance of getting this fixed soon? Now is when many instructors who are new to Wikipedia will be trying to set up their course pages, and the mislabeled tab is likely to confuse.",SOLUTION USAGE
55445,VisualEditor: Metadata information missing from transaction when content is inserted,"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",task_description,"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",BUG REPRODUCTION
242791,VisualEditor: Metadata information missing from transaction when content is inserted,"Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928",task_subcomment,"Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

GERRIT_URL",ACTION ON ISSUE
242785,VisualEditor: Metadata information missing from transaction when content is inserted,"Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928",task_subcomment,"Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

GERRIT_URL",SOLUTION USAGE
55444,VisualEditor: Metadata should always be collapsed on replace,"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",task_description,"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",BUG REPRODUCTION
242747,VisualEditor: Metadata should always be collapsed on replace,"Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928",task_subcomment,"Change 81928 merged by jenkins-bot:
Collapse metadata on any removal.

GERRIT_URL",ACTION ON ISSUE
242738,VisualEditor: Metadata should always be collapsed on replace,"Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

https://gerrit.wikimedia.org/r/81928",task_subcomment,"Change 81928 had a related patch set uploaded by Cscott:
Collapse metadata on any removal.

GERRIT_URL",SOLUTION USAGE
55436,"VisualEditor: Style Parsoid's 
    s to look like MediaWiki's 
    s rather than replacing them","Right now VisualEditor transforms the HTML Parsoid gives us (which is nicely-structured 
    s) into the mess of 
    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 
    s with known classes (and Parsoid's HTML has no 
    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",task_description,"Right now VisualEditor transforms the HTML Parsoid gives us (which is nicely-structured 
    s) into the mess of 
    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 
    s with known classes (and Parsoid's HTML has no 
    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",INVESTIGATION AND EXPLORATION
242319,"VisualEditor: Style Parsoid's 
    s to look like MediaWiki's 
    s rather than replacing them","Change 93417 merged by jenkins-bot:
Render CE MWBlockImageNodes as styled 
    s

https://gerrit.wikimedia.org/r/93417",task_subcomment,"Change 93417 merged by jenkins-bot:
Render CE MWBlockImageNodes as styled 
    s

GERRIT_URL",ACTION ON ISSUE
242317,"VisualEditor: Style Parsoid's 
    s to look like MediaWiki's 
    s rather than replacing them","Change 93417 had a related patch set uploaded by Jforrester:
Render CE MWBlockImageNodes as styled 
    s

https://gerrit.wikimedia.org/r/93417",task_subcomment,"Change 93417 had a related patch set uploaded by Jforrester:
Render CE MWBlockImageNodes as styled 
    s

GERRIT_URL",TASK PROGRESS
55413,"TemplateData: Consider support for non-template transclusions (magic words, parser functions)","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",task_description,"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",INVESTIGATION AND EXPLORATION
1960990,"TemplateData: Consider support for non-template transclusions (magic words, parser functions)","Change 819740 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[mediawiki/extensions/TemplateData@master] Specification.md: Update to add parser functions and extension tags%%%
https://gerrit.wikimedia.org/r/819740",task_subcomment,"Change 819740 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):
%%%[mediawiki/extensions/TemplateData@master] Specification.md: Update to add parser functions and extension tags%%%
GERRIT_URL",SOLUTION USAGE
1959573,"TemplateData: Consider support for non-template transclusions (magic words, parser functions)","Briefly: {T204371} proposing allowing a vertical pipe to separate the first argument of a parser function, so that's not necessarily an issue.  {T204307} proposes allowing parser functions to opt-in to the ""standard"" named-argument processing such as used in templates, which I think is a better way of solving that particular problem in the long term than teaching VE/Parsoid a whole new set of serialization options.

In general I'd like to have a ""parser function syntax"" alternative for every extension and magic word, so that we wouldn't ""need"" the `type` parameter, we'd just always look up the various constructs in their ""parser function form"".  The one tricky case is extensions, which do already have a parser function form in `{{#tag}}` but then would need an additional extension hook because `{{#tag}}` is used for *every* extension.  It's a little awkward, because I don't ""really"" want to have to do dynamic dispatch on both the first argument *and* the parser function name, but I guess doing so would help with {{#invoke}} as well, so maybe I just need to support delegation.",task_subcomment,"Briefly: {T204371} proposing allowing a vertical pipe to separate the first argument of a parser function, so that's not necessarily an issue.  {T204307} proposes allowing parser functions to opt-in to the ""standard"" named-argument processing such as used in templates, which I think is a better way of solving that particular problem in the long term than teaching VE/Parsoid a whole new set of serialization options.

In general I'd like to have a ""parser function syntax"" alternative for every extension and magic word, so that we wouldn't ""need"" the CODE parameter, we'd just always look up the various constructs in their ""parser function form"".  The one tricky case is extensions, which do already have a parser function form in CODE but then would need an additional extension hook because CODE is used for *every* extension.  It's a little awkward, because I don't ""really"" want to have to do dynamic dispatch on both the first argument *and* the parser function name, but I guess doing so would help with {{#invoke}} as well, so maybe I just need to support delegation.",SOLUTION DISCUSSION
55385,VisualEditor: Cursor movement stalls after cut-pasting text containing ref tags,"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",task_description,"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",BUG REPRODUCTION
401464,VisualEditor: Cursor movement stalls after cut-pasting text containing ref tags," Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2/production. 

",task_subcomment," Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2/production. 

",BUG REPRODUCTION
400967,VisualEditor: Cursor movement stalls after cut-pasting text containing ref tags," Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2. 

Since it's an old bug - marking it's an invalid for now. ",task_subcomment," Firefox and Chrome on Mac - a cursor, when moved with arrow keys,  successfully skips the ref section.  Checked in test2. 

Since it's an old bug - marking it's an invalid for now. ",BUG REPRODUCTION
55375,VisualEditor: Firefox doesn't fire a copy event when only a FocusableNode is selected,"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",task_description,"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",WORKAROUNDS
239233,VisualEditor: Firefox doesn't fire a copy event when only a FocusableNode is selected,"Change 83222 merged by jenkins-bot:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222",task_subcomment,"Change 83222 merged by jenkins-bot:
The Great [...] Rewrite of 2013: Clipboard edition

GERRIT_URL",ACTION ON ISSUE
239227,VisualEditor: Firefox doesn't fire a copy event when only a FocusableNode is selected,"Change 83222 had a related patch set uploaded by Esanders:
The Great [...] Rewrite of 2013: Clipboard edition

https://gerrit.wikimedia.org/r/83222",task_subcomment,"Change 83222 had a related patch set uploaded by Esanders:
The Great [...] Rewrite of 2013: Clipboard edition

GERRIT_URL",SOLUTION USAGE
55366,VisualEditor: getNearestCorrectOffset doesn't ignore internal lists,"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",task_description,"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",BUG REPRODUCTION
238731,VisualEditor: getNearestCorrectOffset doesn't ignore internal lists,"ElementLinearData#getRelativeOffset now checks for handlesOwnChildren, which prevents this from being an issue.",task_subcomment,"ElementLinearData#getRelativeOffset now checks for handlesOwnChildren, which prevents this from being an issue.",SOLUTION DISCUSSION
238723,VisualEditor: getNearestCorrectOffset doesn't ignore internal lists,May have been ameliorated by https://gerrit.wikimedia.org/r/98515,task_subcomment,May have been ameliorated by GERRIT_URL,SOLUTION DISCUSSION
55365,VisualEditor: Unnamed references don't register when cloned,"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",task_description,"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",BUG REPRODUCTION
238675,VisualEditor: Unnamed references don't register when cloned,"Change 81417 merged by jenkins-bot:
Always give references names. Ignore if used once.

https://gerrit.wikimedia.org/r/81417",task_subcomment,"Change 81417 merged by jenkins-bot:
Always give references names. Ignore if used once.

GERRIT_URL",TASK PROGRESS
238672,VisualEditor: Unnamed references don't register when cloned,"Change 81417 had a related patch set uploaded by Esanders:
Always give references names. Ignore if used once.

https://gerrit.wikimedia.org/r/81417",task_subcomment,"Change 81417 had a related patch set uploaded by Esanders:
Always give references names. Ignore if used once.

GERRIT_URL",TASK PROGRESS
55364,VisualEditor: [Regression] Copying over nodes results in paste adding newlines,"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",task_description,"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",BUG REPRODUCTION
238631,VisualEditor: [Regression] Copying over nodes results in paste adding newlines,"Change 81028 merged by jenkins-bot:
When pasting, try to use original range

https://gerrit.wikimedia.org/r/81028",task_subcomment,"Change 81028 merged by jenkins-bot:
When pasting, try to use original range

GERRIT_URL",ACTION ON ISSUE
238622,VisualEditor: [Regression] Copying over nodes results in paste adding newlines,"Change 81028 had a related patch set uploaded by Esanders:
When pasting, try to use original range

https://gerrit.wikimedia.org/r/81028",task_subcomment,"Change 81028 had a related patch set uploaded by Esanders:
When pasting, try to use original range

GERRIT_URL",ACTION ON ISSUE
55362,VisualEditor: Document loses focus after cutting a FocusableNode,"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",task_description,"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",BUG REPRODUCTION
238550,VisualEditor: Document loses focus after cutting a FocusableNode,Fixed in master; will be deployed on Thursday as part of the regular push.,task_subcomment,Fixed in master; will be deployed on Thursday as part of the regular push.,SOLUTION USAGE
238545,VisualEditor: Document loses focus after cutting a FocusableNode,"Change 81027 merged by jenkins-bot:
Give document real focus after cut

https://gerrit.wikimedia.org/r/81027",task_subcomment,"Change 81027 merged by jenkins-bot:
Give document real focus after cut

GERRIT_URL",ACTION ON ISSUE
238535,VisualEditor: Document loses focus after cutting a FocusableNode,"Change 81027 had a related patch set uploaded by Jforrester:
Give document real focus after cut

https://gerrit.wikimedia.org/r/81027",task_subcomment,"Change 81027 had a related patch set uploaded by Jforrester:
Give document real focus after cut

GERRIT_URL",ACTION ON ISSUE
238529,VisualEditor: Document loses focus after cutting a FocusableNode,https://gerrit.wikimedia.org/r/#/c/81027/ fixes,task_subcomment,URL fixes,ACTION ON ISSUE
55360,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"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}",task_description,"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}",BUG REPRODUCTION
238443,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"This has been fixed in VisualEditor master as part of gerrit 81213, and we will do an emergency push of this to wmf14 tomorrow to fix it in product; sorry for the disruption.",task_subcomment,"This has been fixed in VisualEditor master as part of gerrit 81213, and we will do an emergency push of this to wmf14 tomorrow to fix it in product; sorry for the disruption.",ACTION ON ISSUE
238435,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),I should mention that the (corrupted) diff view contents is what is actually saved when finally saving the page in VE,task_subcomment,I should mention that the (corrupted) diff view contents is what is actually saved when finally saving the page in VE,BUG REPRODUCTION
238429,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"I can reproduce this consistently on test2wiki most of the time manually and automatedly all of the time as of the last VE deploy.  To repro manually (I use Chrome): 

* Pick a random page on test2wiki that has existing text
* click Edit for VE. click no other thing.
* Poise your right hand so that you are prepared to click 'Save page'
* With your left hand type randomly very very quickly. While typing with your left hand, click 'Save page' with your right hand

* take a look at the VE page contents (CE I assume).  It will appear to be accurate.  It will be different than what is in the diff view (DM I assume). 

Note: the automated test moves quickly enough that *nothing* typed into the VE edit interface is reflected in the diff view.  I can demo this if you'd like.

Again, this is new behavior as of Aug 26.",task_subcomment,"I can reproduce this consistently on test2wiki most of the time manually and automatedly all of the time as of the last VE deploy.  To repro manually (I use Chrome): 

* Pick a random page on test2wiki that has existing text
* click Edit for VE. click no other thing.
* Poise your right hand so that you are prepared to click 'Save page'
* With your left hand type randomly very very quickly. While typing with your left hand, click 'Save page' with your right hand

* take a look at the VE page contents (CE I assume).  It will appear to be accurate.  It will be different than what is in the diff view (DM I assume). 

Note: the automated test moves quickly enough that *nothing* typed into the VE edit interface is reflected in the diff view.  I can demo this if you'd like.

Again, this is new behavior as of Aug 26.",BUG REPRODUCTION
238423,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"I still can't reproduce these in Chrome/Firefox/Safari/Opera testing on local master, on production test2, or production enwiki/mediawikiwiki.

What does ""can also be triggered manually"" mean - how? Or is this an unreliable/occasional thing? Possibly a system-load issue?

Is this specific to test2?

From the screenshots, the displayed content (from CE) and the data model (in DM) appear to have gotten out of sync, which Shouldn't Ever Happen(tm).",task_subcomment,"I still can't reproduce these in Chrome/Firefox/Safari/Opera testing on local master, on production test2, or production enwiki/mediawikiwiki.

What does ""can also be triggered manually"" mean - how? Or is this an unreliable/occasional thing? Possibly a system-load issue?

Is this specific to test2?

From the screenshots, the displayed content (from CE) and the data model (in DM) appear to have gotten out of sync, which Shouldn't Ever Happen(tm).",BUG REPRODUCTION
238418,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"Created attachment 13176
example 3

**Attached**: {F11316}",task_subcomment,"Created attachment 13176
example 3

**Attached**: {F11316}",ACTION ON ISSUE
238413,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"Created attachment 13175
example 3

**Attached**: {F11315}",task_subcomment,"Created attachment 13175
example 3

**Attached**: {F11315}",ACTION ON ISSUE
238407,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"Created attachment 13174
example 2

**Attached**: {F11312}",task_subcomment,"Created attachment 13174
example 2

**Attached**: {F11312}",ACTION ON ISSUE
238401,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"Created attachment 13173
example 2

**Attached**: {F11311}",task_subcomment,"Created attachment 13173
example 2

**Attached**: {F11311}",ACTION ON ISSUE
238395,VisualEditor: Displayed content and DM out of sync with fast insertion (primarily from test scripts?),"Created attachment 13172
example 1

**Attached**: {F11310}",task_subcomment,"Created attachment 13172
example 1

**Attached**: {F11310}",SOLUTION USAGE
55345,VisualEditor: Creating a new reference with blank content leads to insertion of a  tag in the wikitext,"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",task_description,"See URL for an example - I'm not sure what the problem is, here, since that's a meaningless tag :/.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
237658,VisualEditor: Creating a new reference with blank content leads to insertion of a  tag in the wikitext,Fixed in master; will be deployed on Thursday as part of the regular push.,task_subcomment,Fixed in master; will be deployed on Thursday as part of the regular push.,SOLUTION USAGE
237652,VisualEditor: Creating a new reference with blank content leads to insertion of a  tag in the wikitext,"Change 81438 merged by jenkins-bot:
Disable inserting/changing references when surface widget is empty

https://gerrit.wikimedia.org/r/81438",task_subcomment,"Change 81438 merged by jenkins-bot:
Disable inserting/changing references when surface widget is empty

GERRIT_URL",ACTION ON ISSUE
237647,VisualEditor: Creating a new reference with blank content leads to insertion of a  tag in the wikitext,"Change 81438 had a related patch set uploaded by Esanders:
Disable inserting/changing references when surface widget is empty

https://gerrit.wikimedia.org/r/81438",task_subcomment,"Change 81438 had a related patch set uploaded by Esanders:
Disable inserting/changing references when surface widget is empty

GERRIT_URL",ACTION ON ISSUE
237642,VisualEditor: Creating a new reference with blank content leads to insertion of a  tag in the wikitext,"Looks like it's what happens when you insert a reference without typing anything into the box. Hit ""insert reference"", leave the main field blank, go immediately to the insert button, and... https://pl.wikipedia.org/w/index.php?title=Wikipedysta%3AOkeyes_%28WMF%29&diff=37370424&oldid=37257359",task_subcomment,"Looks like it's what happens when you insert a reference without typing anything into the box. Hit ""insert reference"", leave the main field blank, go immediately to the insert button, and... URL",BUG REPRODUCTION
55303,"Don't allow nested s, because Cite.php doesn't","From http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#VE.2C_Sfn_template_within_reference.2C_Vcite_error

Adding a  tag (e.g., a bibliographic citation) inside another  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",task_description,"From URL

Adding a  tag (e.g., a bibliographic citation) inside another  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**: URL",SOLUTION DISCUSSION
235284,"Don't allow nested s, because Cite.php doesn't","We have mismatched behavior.  Either *both* systems should display nested refs, or VisualEditor should stop displaying nested refs to match the limited features available to readers.

Whether this mismatch should be solved by reducing VisualEditor's ability to process nested refs or by increasing the other system's ability to process nested refs is beyond my paygrade.",task_subcomment,"We have mismatched behavior.  Either *both* systems should display nested refs, or VisualEditor should stop displaying nested refs to match the limited features available to readers.

Whether this mismatch should be solved by reducing VisualEditor's ability to process nested refs or by increasing the other system's ability to process nested refs is beyond my paygrade.",SOLUTION DISCUSSION
235274,"Don't allow nested s, because Cite.php doesn't","(In reply to comment #0)
> Adding a  tag (e.g., a bibliographic citation) inside another  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 Bug
> 20707
> in Cite.php

If this problem is covered in bug 20707 already I'm not sure what your intention was to file another bug report. Could you clarify please?",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

If this problem is covered in bug 20707 already I'm not sure what your intention was to file another bug report. Could you clarify please?",ACTION ON ISSUE
55251,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing","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",task_description,"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**:
URL",SOLUTION DISCUSSION
257059,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing",verified in test2:https://test2.wikipedia.org/w/index.php?title=13th_december&veaction=edit,task_subcomment,verified in test2:URL,TESTING
257052,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing",Verified in Betalabs,task_subcomment,Verified in Betalabs,TASK PROGRESS
257045,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing",This is now fixed in betalabs after we caused the English messages to get re-synched.,task_subcomment,This is now fixed in betalabs after we caused the English messages to get re-synched.,SOLUTION USAGE
257040,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing",okay but I checked it on Betalabs.,task_subcomment,okay but I checked it on Betalabs.,TASK PROGRESS
257034,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing","@ryasmeen Fixed != deployed to production. That happens at a later time, usually somewhere within 2 weeks after getting fixed.",task_subcomment,"SCREEN_NAME Fixed != deployed to production. That happens at a later time, usually somewhere within 2 weeks after getting fixed.",ACTION ON ISSUE
257028,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing",I am still seeing label Latex instead of Formula,task_subcomment,I am still seeing label Latex instead of Formula,BUG REPRODUCTION
257021,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing","Change 100112 merged by jenkins-bot:
Re-label the formula inspector to not be LaTeX

https://gerrit.wikimedia.org/r/100112",task_subcomment,"Change 100112 merged by jenkins-bot:
Re-label the formula inspector to not be LaTeX

GERRIT_URL",ACTION ON ISSUE
257015,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing","Change 100112 had a related patch set uploaded by Jforrester:
Re-label the formula inspector to not be LaTeX

https://gerrit.wikimedia.org/r/100112",task_subcomment,"Change 100112 had a related patch set uploaded by Jforrester:
Re-label the formula inspector to not be LaTeX

GERRIT_URL",ACTION ON ISSUE
257009,"VisualEditor: Math editor is called LaTeX, but that is not accurate and possibly confusing","I'm minded to just call it ""Formula"". Thoughts?",task_subcomment,"I'm minded to just call it ""Formula"". Thoughts?",SOLUTION DISCUSSION
55228,Nowiki tag not properly escaped when combined with other wiki markup,"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  tag '''here'''.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"From URL

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  tag '''here'''.

--------------------------
**Version**: unspecified
**Severity**: normal",SOLUTION DISCUSSION
255560,Nowiki tag not properly escaped when combined with other wiki markup,"Change 137525 merged by jenkins-bot:
Escape nowiki when combined with other wiki markup

https://gerrit.wikimedia.org/r/137525",task_subcomment,"Change 137525 merged by jenkins-bot:
Escape nowiki when combined with other wiki markup

GERRIT_URL",ACTION ON ISSUE
255553,Nowiki tag not properly escaped when combined with other wiki markup,"Change 137525 had a related patch set uploaded by Arlolra:
Escape nowiki when combined with other wiki markup

https://gerrit.wikimedia.org/r/137525",task_subcomment,"Change 137525 had a related patch set uploaded by Arlolra:
Escape nowiki when combined with other wiki markup

GERRIT_URL",SOLUTION USAGE
255546,Nowiki tag not properly escaped when combined with other wiki markup,"This is a Parsoid serializer bug:

[subbu@earth tests] echo '* </nowiki> tag' | node parse --html2wt
*  tag",task_subcomment,"This is a Parsoid serializer bug:

[subbu@earth tests] echo '* </nowiki> tag' | node parse --html2wt
*  tag",BUG REPRODUCTION
55214,"Slugs are created inside empty table rows, creating pawns if used","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",task_description,"At URL it seems that a table ending with trailing new line syntax

|-
|}

caused pawns to be added to the article. As discussed at URL 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",BUG REPRODUCTION
254487,"Slugs are created inside empty table rows, creating pawns if used","Change 119067 merged by jenkins-bot:
Only insert slugs where paragraphs are allowed

https://gerrit.wikimedia.org/r/119067",task_subcomment,"Change 119067 merged by jenkins-bot:
Only insert slugs where paragraphs are allowed

GERRIT_URL",ACTION ON ISSUE
254479,"Slugs are created inside empty table rows, creating pawns if used","Change 119067 had a related patch set uploaded by Esanders:
Only insert slugs where paragraphs are allowed

https://gerrit.wikimedia.org/r/119067",task_subcomment,"Change 119067 had a related patch set uploaded by Esanders:
Only insert slugs where paragraphs are allowed

GERRIT_URL",TASK PROGRESS
254471,"Slugs are created inside empty table rows, creating pawns if used",I think this edit https://fr.wikipedia.org/w/index.php?title=Cash_investigation&diff=96500094&oldid=95914321 is related.,task_subcomment,I think this edit URL is related.,POTENTIAL NEW ISSUES AND REQUESTS
254465,"Slugs are created inside empty table rows, creating pawns if used","(In reply to comment #2)
> To perhaps clarify, VE and parsoid should accept both
> 
> |content
> |-
> |}
> 
> and
> 
> |content
> |}
> 
> as validly closed templates that should be displayed and rendered
> identically.

We currently don't strip empty table rows, which seems to be done in some conditions in the PHP parser + tidy combo. We could emulate this behavior in templated content and maybe also outside of templated content, but will need to avoid dirty diffs and preserve WYSIWYG behavior even when another row is added in VE.

> Both syntaxes should be retained as is when roundtripping.

This should already be the case in Parsoid. I just verified this at http://parsoid.wmflabs.org/_rtform/. Pawn insertion would a DOM modification in VE.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

We currently don't strip empty table rows, which seems to be done in some conditions in the PHP parser + tidy combo. We could emulate this behavior in templated content and maybe also outside of templated content, but will need to avoid dirty diffs and preserve WYSIWYG behavior even when another row is added in VE.

QUOTE

This should already be the case in Parsoid. I just verified this at URL Pawn insertion would a DOM modification in VE.",SOLUTION DISCUSSION
254461,"Slugs are created inside empty table rows, creating pawns if used","To perhaps clarify, VE and parsoid should accept both

|content
|-
|}

and

|content
|}

as validly closed templates that should be displayed and rendered identically. Both syntaxes should be retained as is when roundtripping.",task_subcomment,"To perhaps clarify, VE and parsoid should accept both

|content
|-
|}

and

|content
|}

as validly closed templates that should be displayed and rendered identically. Both syntaxes should be retained as is when roundtripping.",SOLUTION DISCUSSION
254459,"Slugs are created inside empty table rows, creating pawns if used",Pawns are firmly VE territory. Moving to the VisualEditor product.,task_subcomment,Pawns are firmly VE territory. Moving to the VisualEditor product.,ACTION ON ISSUE
55206,"VisualEditor: Blank page, list, [enter] lose cursor","<>

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",task_description,"<>

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",BUG REPRODUCTION
254051,"VisualEditor: Blank page, list, [enter] lose cursor",This was fixed a long while ago.,task_subcomment,This was fixed a long while ago.,ISSUE CONTENT MANAGEMENT
55151,VisualEditor: MW images shouldn't be able to take a link annotation,"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",task_description,"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",BUG REPRODUCTION
251316,VisualEditor: MW images shouldn't be able to take a link annotation,"Change 85010 merged by jenkins-bot:
Node annotation blacklists

https://gerrit.wikimedia.org/r/85010",task_subcomment,"Change 85010 merged by jenkins-bot:
Node annotation blacklists

GERRIT_URL",ACTION ON ISSUE
251310,VisualEditor: MW images shouldn't be able to take a link annotation,"Change 85011 merged by jenkins-bot:
MW*ImageNode's can't take link annotations

https://gerrit.wikimedia.org/r/85011",task_subcomment,"Change 85011 merged by jenkins-bot:
MW*ImageNode's can't take link annotations

GERRIT_URL",ACTION ON ISSUE
251302,VisualEditor: MW images shouldn't be able to take a link annotation,"Change 85011 had a related patch set uploaded by Esanders:
MW*ImageNode's can't take link annotations

https://gerrit.wikimedia.org/r/85011",task_subcomment,"Change 85011 had a related patch set uploaded by Esanders:
MW*ImageNode's can't take link annotations

GERRIT_URL",ACTION ON ISSUE
251293,VisualEditor: MW images shouldn't be able to take a link annotation,"Change 85010 had a related patch set uploaded by Esanders:
Node annotation blacklists

https://gerrit.wikimedia.org/r/85010",task_subcomment,"Change 85010 had a related patch set uploaded by Esanders:
Node annotation blacklists

GERRIT_URL",ACTION ON ISSUE
55143,Implement non-linear transitions,"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",task_description,"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",SOLUTION DISCUSSION
250806,Implement non-linear transitions,"Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

https://gerrit.wikimedia.org/r/116228",task_subcomment,"Change 116228 merged by jenkins-bot:
Refactor and add non-linear tours, with tests

GERRIT_URL",ACTION ON ISSUE
250796,Implement non-linear transitions,"Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours

https://gerrit.wikimedia.org/r/116228",task_subcomment,"Change 116228 had a related patch set uploaded by Mattflaschen:
WIP: Refactor and add non-linear tours

GERRIT_URL",SOLUTION DISCUSSION
55079,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"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",task_description,"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",BUG REPRODUCTION
247320,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),*** Bug 53317 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53317 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
247314,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"Change 81213 merged by jenkins-bot:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213",task_subcomment,"Change 81213 merged by jenkins-bot:
Detect outdated pending post KeyPress handler

GERRIT_URL",ACTION ON ISSUE
247308,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),Further to my previous comment: it seems that it's actually onDocumentKeyPress which is doing the setTimeout which gets outdated; and that we can code our way around it because it's just there to do a surface-to-model poll.,task_subcomment,Further to my previous comment: it seems that it's actually onDocumentKeyPress which is doing the setTimeout which gets outdated; and that we can code our way around it because it's just there to do a surface-to-model poll.,SOLUTION DISCUSSION
247301,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"Change 81213 had a related patch set uploaded by Divec:
Detect outdated pending post KeyPress handler

https://gerrit.wikimedia.org/r/81213",task_subcomment,"Change 81213 had a related patch set uploaded by Divec:
Detect outdated pending post KeyPress handler

GERRIT_URL",ACTION ON ISSUE
247293,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"I can reproduce this just by holding a key down for a few seconds. It seems to be because of setTimeout( f(), 0 ) causing event handling to overlap. This could be challenging to resolve because of the way browser event handling works. Gory details below :-)

On my slow Ubuntu laptop, I can reliably reproduce the bug. It happens if I just hold the 'x' key down inside a 
     for a couple of seconds.

I'm pretty sure it's happening because we use setTimeout to process events. This can get complex up when two events are emitted by the browser at virtually the same time. In this case, ve.ce.SurfaceObserver.onDocumentKeyDown receives event 1, does some processing, then effectively does a setTimeout( f(), 0 ) to finish the processing. But by that time, the browser has already queued the handlers for event 2, so the processing for event 2 will start before the processing for event 1 has finished.

I tested this by putting two lines at the top of onDocumentKeydown: a ve.log(""main..."") and a setTimeout( ve.log(""post...""), 0) . The corruption happens exactly when we get ""main..."" twice in a row followed by ""post..."" twice in a row. See http://pastebin.com/dzGYbpDq for full output.

This may be challenging to resolve, because we probably need to do stuff both before and after the browser's native keydown handler. We can't manage all the handling in our own queue, because (afaik) the browser's native handling can't be postponed. So it seems the only obvious option would be to detect when there are overlapping events, and try and do act delicately enough that things don't break.

Timo, any thoughts?",task_subcomment,"I can reproduce this just by holding a key down for a few seconds. It seems to be because of setTimeout( f(), 0 ) causing event handling to overlap. This could be challenging to resolve because of the way browser event handling works. Gory details below :-)

On my slow Ubuntu laptop, I can reliably reproduce the bug. It happens if I just hold the 'x' key down inside a 
     for a couple of seconds.

I'm pretty sure it's happening because we use setTimeout to process events. This can get complex up when two events are emitted by the browser at virtually the same time. In this case, ve.ce.SurfaceObserver.onDocumentKeyDown receives event 1, does some processing, then effectively does a setTimeout( f(), 0 ) to finish the processing. But by that time, the browser has already queued the handlers for event 2, so the processing for event 2 will start before the processing for event 1 has finished.

I tested this by putting two lines at the top of onDocumentKeydown: a ve.log(""main..."") and a setTimeout( ve.log(""post...""), 0) . The corruption happens exactly when we get ""main..."" twice in a row followed by ""post..."" twice in a row. See URL for full output.

This may be challenging to resolve, because we probably need to do stuff both before and after the browser's native keydown handler. We can't manage all the handling in our own queue, because (afaik) the browser's native handling can't be postponed. So it seems the only obvious option would be to detect when there are overlapping events, and try and do act delicately enough that things don't break.

Timo, any thoughts?",BUG REPRODUCTION
247287,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"This is problematic, since I couldn't properly and reliably replicate the bug since then, it only happens occasionally, I'm not sure if it's because of the speed or some other aspect. 

But I did find that it happens not only with the Bold button - it happens either with ""just"" rapid text (no annotation) and with strikethrough and italics as well. I think it's probably safe to say that this isn't a specific annotation bug.

Another small detail about that bug was that once it *does* happen, the rest of the editing is a mess -- that is, once it happens, even if I stop rapid typing, and then start editing normally, I still get random letters and gibberish added, and the 'delete' functionality goes wonky. To get rid of it I need to refresh the page and start over. 

Also, This happened on my local wiki (using current VisualEditor master), installed on Ubuntu 13.04, and used through Firefox, and I just replicated it in MediaWiki.org",task_subcomment,"This is problematic, since I couldn't properly and reliably replicate the bug since then, it only happens occasionally, I'm not sure if it's because of the speed or some other aspect. 

But I did find that it happens not only with the Bold button - it happens either with ""just"" rapid text (no annotation) and with strikethrough and italics as well. I think it's probably safe to say that this isn't a specific annotation bug.

Another small detail about that bug was that once it *does* happen, the rest of the editing is a mess -- that is, once it happens, even if I stop rapid typing, and then start editing normally, I still get random letters and gibberish added, and the 'delete' functionality goes wonky. To get rid of it I need to refresh the page and start over. 

Also, This happened on my local wiki (using current VisualEditor master), installed on Ubuntu 13.04, and used through Firefox, and I just replicated it in MediaWiki.org",BUG REPRODUCTION
247281,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"<>

http://www.mediawiki.org/w/index.php?title=User:Chris857&oldid=770602
http://en.wikipedia.org/wiki/File:Visual_Editor_-_subscript_and_superscript.PNG
http://en.wikipedia.org/wiki/File:Wikitext_editor_-_subscript_and_superscript.PNG

The user think this is related to the new super/sub script features.


I don't think it has to do with them. Proof is, I can reproduce (on Mediawiki) the same bug without using them. You just need to add quickly casual sequences of words, as if you were vandalizing the page. In this diff http://www.mediawiki.org/w/index.php?title=User:Elitre_(WMF)/SandboxVE&diff=prev&oldid=771184 I kept writing on the third line, it was VE which splitted what I wrote on more lines. I was also able to reproduce the difference among the content you ""write"" and the one which is saved. I can recall a vaguely similar behavior (not with casual letters though) when starting a list, but I can't say which bug that would be. I am also not sure whether this is a real bug or some counter-vandalism filter in action :)
Thanks.",task_subcomment,"<>

URL
URL
URL

The user think this is related to the new super/sub script features.


I don't think it has to do with them. Proof is, I can reproduce (on Mediawiki) the same bug without using them. You just need to add quickly casual sequences of words, as if you were vandalizing the page. In this diff URL I kept writing on the third line, it was VE which splitted what I wrote on more lines. I was also able to reproduce the difference among the content you ""write"" and the one which is saved. I can recall a vaguely similar behavior (not with casual letters though) when starting a list, but I can't say which bug that would be. I am also not sure whether this is a real bug or some counter-vandalism filter in action :)
Thanks.",MOTIVATION
247274,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"Hi Moriel, David, can you please specify on which wiki this happens?
I am not able to reproduce it on en.wp or it.wp, 
but it does happen on mw.org - even if you do not use the Bold button or the new features, like another user suggested. 
I'd say this bug probably needs to be renamed.",task_subcomment,"Hi Moriel, David, can you please specify on which wiki this happens?
I am not able to reproduce it on en.wp or it.wp, 
but it does happen on mw.org - even if you do not use the Bold button or the new features, like another user suggested. 
I'd say this bug probably needs to be renamed.",BUG REPRODUCTION
247268,VisualEditor: Rapid typing with pre-annotation creates weird new characters (sometimes?),"I can reproduce this in Firefox but not in Chromium, on a slowish Ubuntu machine.",task_subcomment,"I can reproduce this in Firefox but not in Chromium, on a slowish Ubuntu machine.",BUG REPRODUCTION
55071,about=null entries on 
     elements (because of dom-fragment reuse),"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]] ([[:fr:Discussion Utilisateur:NicoV|Talk on frwiki]]) 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",task_description,"From WP:VE/F page (URL

------------------------------
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 [URL diff]. It seems to be reproducible on this article. --[[User:NicoV|NicoV]] ([[:fr:Discussion Utilisateur:NicoV|Talk on frwiki]]) 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**:
URL",BUG REPRODUCTION
246783,about=null entries on 
     elements (because of dom-fragment reuse),I am marking this resolved. Haven't seen any reports about this in a while.,task_subcomment,I am marking this resolved. Haven't seen any reports about this in a while.,ACTION ON ISSUE
246780,about=null entries on 
     elements (because of dom-fragment reuse),Is this still happening in production?,task_subcomment,Is this still happening in production?,TASK PROGRESS
246778,about=null entries on 
     elements (because of dom-fragment reuse),https://gerrit.wikimedia.org/r/#/c/83216/ fixes the dsr inconsistency warnings  reported in this bug.,task_subcomment,URL fixes the dsr inconsistency warnings  reported in this bug.,SOLUTION USAGE
246775,about=null entries on 
     elements (because of dom-fragment reuse),"Sorry, I linked the wrong bug which is how you got the email ;-) .. fixing it.",task_subcomment,"Sorry, I linked the wrong bug which is how you got the email ;-) .. fixing it.",ACTION ON ISSUE
246772,about=null entries on 
     elements (because of dom-fragment reuse),"You guys sure you wanted me on the CC for this bug?  I'm just making sure it wasn't another ""Dan"" :)",task_subcomment,"You guys sure you wanted me on the CC for this bug?  I'm just making sure it wasn't another ""Dan"" :)",SOCIAL CONVERSATION
246769,about=null entries on 
     elements (because of dom-fragment reuse),"Based on IRC discussions, we figured that there are different bugs that are interaction and producing the same end result -- duplication in some cases.  The Trieste bug could be a result of a bad parse of ''[[Foo|''bar'']]'' and interaction of the about=null issue.  Dalmine seems to be something else.",task_subcomment,"Based on IRC discussions, we figured that there are different bugs that are interaction and producing the same end result -- duplication in some cases.  The Trieste bug could be a result of a bad parse of ''[[Foo|''bar'']]'' and interaction of the about=null issue.  Dalmine seems to be something else.",INVESTIGATION AND EXPLORATION
246765,about=null entries on 
     elements (because of dom-fragment reuse),"This patch addresses the about=""null"" issue.

I am however not 100% sure that this is indeed the root cause for bug 53071. A
scenario I can think of is this:

1) getAboutSiblings returned sibling nodes without about attributes
2) for some reason that is unclear to me those were *not* assigned
   about=""null"" attributes in unpackDOMFragments on reuse
3) the serializer faithfully serialized out the new content


The diffs in
https://it.wikipedia.org/w/index.php?title=Trieste&diff=prev&oldid=61046913
would support this, as the entire image link is duplicated.

The diff in https://it.wikipedia.org/w/index.php?title=Dalmine&oldid=61238456
however looks like an incomplete image duplication. 

There are several figure-related DSR errors when parsing that page of this pattern:

WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 22704; cs: 22817
WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 18478; cs: 18586

Those warnings are still there when parsing the page with fragment reuse
enabled, so this might be a different issue.",task_subcomment,"This patch addresses the about=""null"" issue.

I am however not 100% sure that this is indeed the root cause for bug 53071. A
scenario I can think of is this:

1) getAboutSiblings returned sibling nodes without about attributes
2) for some reason that is unclear to me those were *not* assigned
   about=""null"" attributes in unpackDOMFragments on reuse
3) the serializer faithfully serialized out the new content


The diffs in
URL
would support this, as the entire image link is duplicated.

The diff in URL
however looks like an incomplete image duplication. 

There are several figure-related DSR errors when parsing that page of this pattern:

WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 22704; cs: 22817
WARNING: DSR inconsistency: cs/s mismatch for node: FIGURE s: 18478; cs: 18586

Those warnings are still there when parsing the page with fragment reuse
enabled, so this might be a different issue.",SOLUTION DISCUSSION
246761,about=null entries on 
     elements (because of dom-fragment reuse),"Change 82676 merged by jenkins-bot:
Bug 53071: Handle about-less images better

https://gerrit.wikimedia.org/r/82676",task_subcomment,"Change 82676 merged by jenkins-bot:
Bug 53071: Handle about-less images better

GERRIT_URL",ACTION ON ISSUE
246757,about=null entries on 
     elements (because of dom-fragment reuse),"Change 82676 had a related patch set uploaded by GWicke:
Bug 53071: Handle about-less images better

https://gerrit.wikimedia.org/r/82676",task_subcomment,"Change 82676 had a related patch set uploaded by GWicke:
Bug 53071: Handle about-less images better

GERRIT_URL",SOLUTION USAGE
246750,about=null entries on 
     elements (because of dom-fragment reuse),"One more example:

https://it.wikipedia.org/w/index.php?title=Dalmine&diff=61238476&oldid=61238456",task_subcomment,"One more example:

URL",SOLUTION USAGE
246741,about=null entries on 
     elements (because of dom-fragment reuse),"One more instance now reported on itwiki:

1. Diff: https://it.wikipedia.org/w/index.php?title=Trieste&diff=prev&oldid=61046913 (see 2 images duplicated further down)

2. Open https://it.wikipedia.org/w/index.php?title=Trieste&oldid=61038476&veaction=edit in Chrome and dump Parsoid HTML in the console ""copy(ve.init.mw.targets[0].originalHtml)"" You will see a lot of 
     tags with about=null",task_subcomment,"One more instance now reported on itwiki:

1. Diff: URL (see 2 images duplicated further down)

2. Open URL in Chrome and dump Parsoid HTML in the console ""copy(ve.init.mw.targets[0].originalHtml)"" You will see a lot of 
     tags with about=null",BUG REPRODUCTION
55064,VisualEditor: IME input into an empty slug causes characters to overwrite one another,"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",task_description,"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",BUG REPRODUCTION
246279,VisualEditor: IME input into an empty slug causes characters to overwrite one another,"

*** This bug has been marked as a duplicate of bug 45240 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 45240 ***",ACTION ON ISSUE
55050,VisualEditor: Expose build number,"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",task_description,"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",SOLUTION DISCUSSION
569455,VisualEditor: Expose build number,FYI - This might be removed in {T119750},task_subcomment,FYI - This might be removed in {T119750},ACTION ON ISSUE
245454,VisualEditor: Expose build number,"Change 84334 merged by jenkins-bot:
Hide version info if not available

https://gerrit.wikimedia.org/r/84334",task_subcomment,"Change 84334 merged by jenkins-bot:
Hide version info if not available

GERRIT_URL",ACTION ON ISSUE
245447,VisualEditor: Expose build number,"Change 84334 had a related patch set uploaded by Esanders:
Hide version info if not available

https://gerrit.wikimedia.org/r/84334",task_subcomment,"Change 84334 had a related patch set uploaded by Esanders:
Hide version info if not available

GERRIT_URL",SOLUTION USAGE
245440,VisualEditor: Expose build number,"Yes, there's an issue with our deployment process which prevents it from working ATM. We're working on a fix.",task_subcomment,"Yes, there's an issue with our deployment process which prevents it from working ATM. We're working on a fix.",WORKAROUNDS
245433,VisualEditor: Expose build number,"This isn't working.  When I click on ""Beta"" to see this, it says ""Version false"", with a link to https://en.wikipedia.org/w/false (from userspace) or https://en.wikipedia.org/wiki/false (from article space).",task_subcomment,"This isn't working.  When I click on ""Beta"" to see this, it says ""Version false"", with a link to URL (from userspace) or URL (from article space).",BUG REPRODUCTION
245427,VisualEditor: Expose build number,"Change 81877 merged by jenkins-bot:
Expose version information in the client

https://gerrit.wikimedia.org/r/81877",task_subcomment,"Change 81877 merged by jenkins-bot:
Expose version information in the client

GERRIT_URL",ACTION ON ISSUE
245419,VisualEditor: Expose build number,"Change 81877 had a related patch set uploaded by Esanders:
Expose version information in the client

https://gerrit.wikimedia.org/r/81877",task_subcomment,"Change 81877 had a related patch set uploaded by Esanders:
Expose version information in the client

GERRIT_URL",ACTION ON ISSUE
55045,VisualEditor: Line height on beta warning message is too narrow,"Line height example

See screenshot for 1.25em vs 1.5em.

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F11545}",task_description,"Line height example

See screenshot for 1.25em vs 1.5em.

--------------------------
**Version**: unspecified
**Severity**: trivial

**Attached**: {F11545}",BUG REPRODUCTION
245137,VisualEditor: Line height on beta warning message is too narrow,"Change 79804 merged by jenkins-bot:
Increase line height in beta warning

https://gerrit.wikimedia.org/r/79804",task_subcomment,"Change 79804 merged by jenkins-bot:
Increase line height in beta warning

GERRIT_URL",ACTION ON ISSUE
245132,VisualEditor: Line height on beta warning message is too narrow,"Change 79804 had a related patch set uploaded by Esanders:
Increase line height in beta warning

https://gerrit.wikimedia.org/r/79804",task_subcomment,"Change 79804 had a related patch set uploaded by Esanders:
Increase line height in beta warning

GERRIT_URL",ACTION ON ISSUE
55012,VisualEditor: Repeated insertion of multi-byte characters,"See the third example at https://www.mediawiki.org/w/index.php?title=User:Miya/VE4&oldid=762831.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"See the third example at URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
243323,VisualEditor: Repeated insertion of multi-byte characters,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",task_subcomment,"Marking this as ""FIXED"" on the expectation that it's fixed - please re-open if you find that it is still occurring.",ACTION ON ISSUE
243319,VisualEditor: Repeated insertion of multi-byte characters,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

Please let us know whether it fixes the bug!",task_subcomment,"There's code to address this bug in the following patch, which is due to go live by mediawiki.org on 13 September 2013:

URL

Please let us know whether it fixes the bug!",SOLUTION USAGE
243316,VisualEditor: Repeated insertion of multi-byte characters,"This might have been fixed with the changes in gerrit 79451 - David, does this fit the same pattern?",task_subcomment,"This might have been fixed with the changes in gerrit 79451 - David, does this fit the same pattern?",SOLUTION DISCUSSION
54987,"VisualEditor: Editing toolbar CSS disappears on hover, then the buttons do nothing","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 , and I have the arrow pointer.

--------------------------
**Version**: unspecified
**Severity**: normal",task_description,"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 , and I have the arrow pointer.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
241653,"VisualEditor: Editing toolbar CSS disappears on hover, then the buttons do nothing","Still can't reproduce, unfortunately. :-(",task_subcomment,"Still can't reproduce, unfortunately. :-(",BUG REPRODUCTION
241648,"VisualEditor: Editing toolbar CSS disappears on hover, then the buttons do nothing","My VE just died with a slightly different behavior.  Now, the highlighting and outlining is drawn correctly, and persists, also the pointer is the index finger, indicating elements are click-enabled.  However, clicking Nothing Happens.

FF 23.0.1",task_subcomment,"My VE just died with a slightly different behavior.  Now, the highlighting and outlining is drawn correctly, and persists, also the pointer is the index finger, indicating elements are click-enabled.  However, clicking Nothing Happens.

FF 23.0.1",BUG REPRODUCTION
241644,"VisualEditor: Editing toolbar CSS disappears on hover, then the buttons do nothing","Created attachment 13119
screenshot, I lied

**Attached**: {F11406}",task_subcomment,"Created attachment 13119
screenshot, I lied

**Attached**: {F11406}",ATTACHMENT
54981,"VisualEditor: ""Some magic combination of arrow keys and actions involving the heading level toolbar"" scrambles document","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  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}",task_description,"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  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}",BUG REPRODUCTION
241332,"VisualEditor: ""Some magic combination of arrow keys and actions involving the heading level toolbar"" scrambles document","I *believe* that this may be related to bug 53360, which is now fixed, and so will mark as ""WORKSFORME"" (I can't make ""FIXED"" stand up given the lack of reproducible steps from these kinds of issues).

Sorry for the disruption. :-(",task_subcomment,"I *believe* that this may be related to bug 53360, which is now fixed, and so will mark as ""WORKSFORME"" (I can't make ""FIXED"" stand up given the lack of reproducible steps from these kinds of issues).

Sorry for the disruption. :-(",ACTION ON ISSUE
54913,Move info about template-affected attributes from meta tags into data-mw,"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:


    

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 '
    {{echo|
    }}' | 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",task_description,"We currently use meta tags to mark up template-affected attributes:
URL

This turned out to be problematic for several reasons:

These meta tags can end up in foster-parentable positions for inputs like this:


    

They can end up outside of an extension fragment, which makes it hard to reuse fragments. This currently blocks URL

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 URL

We should work this out further in URL
and implement the resulting spec. 

An issue to consider is the interaction between template content editing (URL and templated attributes. For simple cases like echo '[[{{echo|foo}}]]' | node parse, we currently only add mw:ExpandedAttrs/Transclusion info. For echo '
    {{echo|
    }}' | 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",SOLUTION DISCUSSION
237667,Move info about template-affected attributes from meta tags into data-mw,"This was fixed by 283bfd554bf1, so closing this bug. Please reopen if there is something we overlooked.",task_subcomment,"This was fixed by 283bfd554bf1, so closing this bug. Please reopen if there is something we overlooked.",ACTION ON ISSUE
237662,Move info about template-affected attributes from meta tags into data-mw,Meta tags in foster-parentable positions aren't really an issue anymore.,task_subcomment,Meta tags in foster-parentable positions aren't really an issue anymore.,SOLUTION USAGE
54848,VisualEditor: FlaggedRevs inserts its tabs in the midst of the edit and edit source tabs,"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}",task_description,"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}",SOLUTION USAGE
233854,VisualEditor: FlaggedRevs inserts its tabs in the midst of the edit and edit source tabs,"Change 110862 merged by Catrope:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

https://gerrit.wikimedia.org/r/110862",task_subcomment,"Change 110862 merged by Catrope:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

GERRIT_URL",ACTION ON ISSUE
233846,VisualEditor: FlaggedRevs inserts its tabs in the midst of the edit and edit source tabs,"Change 110862 had a related patch set uploaded by Alex Monk:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

https://gerrit.wikimedia.org/r/110862",task_subcomment,"Change 110862 had a related patch set uploaded by Alex Monk:
Don't try to insert the pending changes in the middle of VE's 'Edit' and 'Edit source'

GERRIT_URL",ACTION ON ISSUE
233839,VisualEditor: FlaggedRevs inserts its tabs in the midst of the edit and edit source tabs,"For me it shows [pending changes][edit] without VE (and the comments indicate this is the intended behaviur), so I think with VE should be [pending changes][edit][edit source].",task_subcomment,"For me it shows [pending changes][edit] without VE (and the comments indicate this is the intended behaviur), so I think with VE should be [pending changes][edit][edit source].",SOLUTION DISCUSSION
54845,VisualEditor: Inspector fails to render correctly for embedded buttons,"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",task_description,"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",SOLUTION DISCUSSION
233583,VisualEditor: Inspector fails to render correctly for embedded buttons,"Change 79055 merged by jenkins-bot:
Fix rendering of inspector for embedded buttons

https://gerrit.wikimedia.org/r/79055",task_subcomment,"Change 79055 merged by jenkins-bot:
Fix rendering of inspector for embedded buttons

GERRIT_URL",ACTION ON ISSUE
233581,VisualEditor: Inspector fails to render correctly for embedded buttons,"Change 79055 had a related patch set uploaded by Esanders:
Fix rendering of inspector for embedded buttons

https://gerrit.wikimedia.org/r/79055",task_subcomment,"Change 79055 had a related patch set uploaded by Esanders:
Fix rendering of inspector for embedded buttons

GERRIT_URL",ACTION ON ISSUE
54771,VisualEditor: Pasting block level elements can lose annotations,"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


    

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
https://bugzilla.wikimedia.org/show_bug.cgi?id=52770",task_description,"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 
URL 
selecting the whole of the final paragraph and coping and pasting loses anotation.

Examining the clipboard in this case its something like


    

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",BUG REPRODUCTION
254115,VisualEditor: Pasting block level elements can lose annotations,Can confirm that this has been incidentally fixed as part of Ed's work on copy-and-paste - tested in Chrome/Firefox/Safari/Opera. (Yay.),task_subcomment,Can confirm that this has been incidentally fixed as part of Ed's work on copy-and-paste - tested in Chrome/Firefox/Safari/Opera. (Yay.),SOLUTION DISCUSSION
254110,VisualEditor: Pasting block level elements can lose annotations,Can't reproduce.,task_subcomment,Can't reproduce.,BUG REPRODUCTION
54752,VisualEditor: Edit to a template somehow removing equals signs in markup?,"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",task_description,"See URL which used URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
399856,VisualEditor: Edit to a template somehow removing equals signs in markup?,AFAICT this is fixed; no recurrences in months have been reported.,task_subcomment,AFAICT this is fixed; no recurrences in months have been reported.,ISSUE CONTENT MANAGEMENT
253210,VisualEditor: Edit to a template somehow removing equals signs in markup?,Aha; sorry :).,task_subcomment,Aha; sorry :).,ACTION ON ISSUE
253205,VisualEditor: Edit to a template somehow removing equals signs in markup?,"Thank you.

(In reply to comment #0)
> 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

I do not use this template. I used a dummy template. This is not created.
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:Frozen-mikan/Template:%E7%A9%BA%E3%81%AE%E5%BC%95%E6%95%B0",task_subcomment,"Thank you.

(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE

I do not use this template. I used a dummy template. This is not created.
URL",ACTION ON ISSUE
54751,Regression: Wikitext for new lists has unnecessary newlines after bullets,"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 
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}",task_description,"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 
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}",INVESTIGATION AND EXPLORATION
253169,Regression: Wikitext for new lists has unnecessary newlines after bullets,"Change 78913 merged by jenkins-bot:
(Bug 52751): Serialize p-wrapped list items correctly

https://gerrit.wikimedia.org/r/78913",task_subcomment,"Change 78913 merged by jenkins-bot:
(Bug 52751): Serialize p-wrapped list items correctly

GERRIT_URL",ACTION ON ISSUE
253165,Regression: Wikitext for new lists has unnecessary newlines after bullets,"Change 78913 had a related patch set uploaded by Subramanya Sastry:
(Bug 52751): Serialize p-wrapped list items correctly

https://gerrit.wikimedia.org/r/78913",task_subcomment,"Change 78913 had a related patch set uploaded by Subramanya Sastry:
(Bug 52751): Serialize p-wrapped list items correctly

GERRIT_URL",ACTION ON ISSUE
253161,Regression: Wikitext for new lists has unnecessary newlines after bullets,git bisect shows that c0de1d5839430e9fde79ff4195caf6841baab0d3 is the culprit.  Will investigate and fix.,task_subcomment,git bisect shows that c0de1d5839430e9fde79ff4195caf6841baab0d3 is the culprit.  Will investigate and fix.,BUG REPRODUCTION
253155,Regression: Wikitext for new lists has unnecessary newlines after bullets,"I suspect this is a regression of some sort.  Can be duplicated with this HTML below (VE wraps li-content in p-tags).

[subbu@earth tests] echo ""
    • a
    "" | node parse --html2wt
Incompatible constraints 1: LI P { a: { min: 0, max: 0 }, b: { min: 1, max: 2 }, min: 0, max: 0 }
* 
a",task_subcomment,"I suspect this is a regression of some sort.  Can be duplicated with this HTML below (VE wraps li-content in p-tags).

[subbu@earth tests] echo ""
    • a
    "" | node parse --html2wt
Incompatible constraints 1: LI P { a: { min: 0, max: 0 }, b: { min: 1, max: 2 }, min: 0, max: 0 }
* 
a",BUG REPRODUCTION
54745,VisualEditor: Add a keyboard shortcut to trigger Save dialog,"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",task_description,"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",SOLUTION USAGE
252803,VisualEditor: Add a keyboard shortcut to trigger Save dialog,"Merging with another suggestion for the same.

*** This bug has been marked as a duplicate of bug 50897 ***",task_subcomment,"Merging with another suggestion for the same.

*** This bug has been marked as a duplicate of bug 50897 ***",ACTION ON ISSUE
252797,VisualEditor: Add a keyboard shortcut to trigger Save dialog,"> Ctrl+Shift+S

Sorry, I meant Alt+Shift+S",task_subcomment,"QUOTE

Sorry, I meant Alt+Shift+S",ACTION ON ISSUE
54716,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"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",task_description,"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",BUG REPRODUCTION
250463,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!",task_subcomment,"Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!",ACTION ON ISSUE
250461,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080",task_subcomment,"Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

GERRIT_URL",ACTION ON ISSUE
250459,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080",task_subcomment,"Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

GERRIT_URL",ACTION ON ISSUE
250457,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"Patch has been reverted due to other issues, sadly.",task_subcomment,"Patch has been reverted due to other issues, sadly.",ACTION ON ISSUE
250455,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,Doesn't seem to be happening any more.,task_subcomment,Doesn't seem to be happening any more.,BUG REPRODUCTION
250454,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"This seems to be caused by a call to surfaceObserver.stop() in Surface's onDocumentKeyDown method, which is wrongly asynchronous. The same problem was affecting Malayalam and probably other scripts/IMEs too.

I *think* it should be fixed by https://gerrit.wikimedia.org/r/#/c/79451 (just merged).",task_subcomment,"This seems to be caused by a call to surfaceObserver.stop() in Surface's onDocumentKeyDown method, which is wrongly asynchronous. The same problem was affecting Malayalam and probably other scripts/IMEs too.

I *think* it should be fixed by URL (just merged).",BUG REPRODUCTION
250450,VisualEditor: cursor places itself after the first character when inserting a group of Japanese characters,"Now I tested it myself on Fedora 18 with Firefox. It happens there too. To reproduce:

1. Enabled the ""Japanese (Anthy)"" keyboard in GNOME input sources.
2. In a VisualEditor window type ""mitsubishi"". It appears as four Kana characters: ""みつびし"".
3. Press the space bar. The four characters change to two Kanji characters: ""三菱"".
4. Press Enter. This accepts the Kanji representation.

Observed: The cursor is placed between 三 and 菱.
Expected: The cursor should be placed after 三菱. That is what happens in other text editors on my system.",task_subcomment,"Now I tested it myself on Fedora 18 with Firefox. It happens there too. To reproduce:

1. Enabled the ""Japanese (Anthy)"" keyboard in GNOME input sources.
2. In a VisualEditor window type ""mitsubishi"". It appears as four Kana characters: ""みつびし"".
3. Press the space bar. The four characters change to two Kanji characters: ""三菱"".
4. Press Enter. This accepts the Kanji representation.

Observed: The cursor is placed between 三 and 菱.
Expected: The cursor should be placed after 三菱. That is what happens in other text editors on my system.",BUG REPRODUCTION
54714,Enable Echo / Notifications on se.wikimedia.org,"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",task_description,"The Swedish chapter would like to get Notifications enabled on their wiki at se.wikimedia.org. Please use the default settings.

Poll here: URL

/Jan
CEO

--------------------------
**Version**: wmf-deployment
**Severity**: enhancement",FUTURE PLAN
250378,Enable Echo / Notifications on se.wikimedia.org,Seems like this wiki was included in the last roll-out.,task_subcomment,Seems like this wiki was included in the last roll-out.,TASK PROGRESS
250373,Enable Echo / Notifications on se.wikimedia.org,"Thank you, it was my pleasure! Bear in mind that this is an additional request to enable it on the chapter wiki, and we do not need to wait for a specific date there, just turn it on at your will.",task_subcomment,"Thank you, it was my pleasure! Bear in mind that this is an additional request to enable it on the chapter wiki, and we do not need to wait for a specific date there, just turn it on at your will.",FUTURE PLAN
250368,Enable Echo / Notifications on se.wikimedia.org,"Thanks, Jan!

It was a pleasure to meet you at Wikimania last week.

I am so glad that the Swedish Wikipedia will be one of the first non-English Wikipedia to deploy Echo next week, as outlined in this release plan:

http://www.mediawiki.org/wiki/Echo/Release_Plan_2013

We're now scheduled to deploy on Tuesday August 20 at 12pm PT - on the French, Polish, Portuguese and Swedish Wikipedias, if all goes well. 

Please let us know if you have any final questions.

Cheers ...",task_subcomment,"Thanks, Jan!

It was a pleasure to meet you at Wikimania last week.

I am so glad that the Swedish Wikipedia will be one of the first non-English Wikipedia to deploy Echo next week, as outlined in this release plan:

URL

We're now scheduled to deploy on Tuesday August 20 at 12pm PT - on the French, Polish, Portuguese and Swedish Wikipedias, if all goes well. 

Please let us know if you have any final questions.

Cheers ...",FUTURE PLAN
250364,Enable Echo / Notifications on se.wikimedia.org,"I don't think Echo is under general deployment yet.

CC'ing Fabrice",task_subcomment,"I don't think Echo is under general deployment yet.

CC'ing Fabrice",FUTURE PLAN
54686,VisualEditor: Register each VE experimental feature individually with the BetaFeatures extension,"Because we love Mark:

http://m.mediawiki.org/wiki/Extension:BetaFeatures

--------------------------
**Version**: unspecified
**Severity**: enhancement",task_description,"Because we love Mark:

URL

--------------------------
**Version**: unspecified
**Severity**: enhancement",FUTURE PLAN
248561,VisualEditor: Register each VE experimental feature individually with the BetaFeatures extension,Done in gerrit 91108.,task_subcomment,Done in gerrit 91108.,SOLUTION USAGE
248554,VisualEditor: Register each VE experimental feature individually with the BetaFeatures extension,"Change 78795 merged by jenkins-bot:
Integrate with BetaPreferences

https://gerrit.wikimedia.org/r/78795",task_subcomment,"Change 78795 merged by jenkins-bot:
Integrate with BetaPreferences

GERRIT_URL",ACTION ON ISSUE
248548,VisualEditor: Register each VE experimental feature individually with the BetaFeatures extension,"Change 78795 had a related patch set uploaded by Esanders:
[WIP] Integrate with BetaPreferences

https://gerrit.wikimedia.org/r/78795",task_subcomment,"Change 78795 had a related patch set uploaded by Esanders:
[WIP] Integrate with BetaPreferences

GERRIT_URL",TASK PROGRESS
54670,VisualEditor: Link suggestions list should vertically scroll if there's insufficient room for them on-screen,"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",task_description,"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",BUG REPRODUCTION
247683,VisualEditor: Link suggestions list should vertically scroll if there's insufficient room for them on-screen,"No, it was in error. Sorry!",task_subcomment,"No, it was in error. Sorry!",ACTION ON ISSUE
247681,VisualEditor: Link suggestions list should vertically scroll if there's insufficient room for them on-screen,"James, did you mean to reopen this four seconds after closing it?",task_subcomment,"James, did you mean to reopen this four seconds after closing it?",ACTION ON ISSUE
247679,VisualEditor: Link suggestions list should vertically scroll if there's insufficient room for them on-screen,I believe that this was fixed in the scrollable-update in October. Sorry for the slow triage.,task_subcomment,I believe that this was fixed in the scrollable-update in October. Sorry for the slow triage.,TASK PROGRESS
54659,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"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}",task_description,"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}",BUG REPRODUCTION
247166,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Change 158659 merged by jenkins-bot:
mediawiki.notification: Also hide #mw-notification-area upon creation

https://gerrit.wikimedia.org/r/158659",task_subcomment,"Change 158659 merged by jenkins-bot:
mediawiki.notification: Also hide #mw-notification-area upon creation

GERRIT_URL",ACTION ON ISSUE
247161,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,*** Bug 55457 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 55457 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
247156,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Change 158659 had a related patch set uploaded by Catrope:
Followup 6c5b246: also hide #mw-notification-area upon creation

https://gerrit.wikimedia.org/r/158659",task_subcomment,"Change 158659 had a related patch set uploaded by Catrope:
Followup 6c5b246: also hide #mw-notification-area upon creation

GERRIT_URL",ACTION ON ISSUE
247150,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Change 109124 merged by jenkins-bot:
mediawiki.notification: Hide #mw-notification-area when it's empty

https://gerrit.wikimedia.org/r/109124",task_subcomment,"Change 109124 merged by jenkins-bot:
mediawiki.notification: Hide #mw-notification-area when it's empty

GERRIT_URL",SOLUTION USAGE
247142,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,Rephrasing bug title as it was cut-off.,task_subcomment,Rephrasing bug title as it was cut-off.,TASK PROGRESS
247133,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Thanks, Bartosz.",task_subcomment,"Thanks, Bartosz.",ACTION ON ISSUE
247127,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Change 109124 had a related patch set uploaded by Bartosz Dziewoński:
mediawiki.notification: Hide #mw-notification-area when it's empty

https://gerrit.wikimedia.org/r/109124",task_subcomment,"Change 109124 had a related patch set uploaded by Bartosz Dziewoński:
mediawiki.notification: Hide #mw-notification-area when it's empty

GERRIT_URL",SOLUTION USAGE
247118,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Ugh, I guess no one will do this if I don't.",task_subcomment,"Ugh, I guess no one will do this if I don't.",CONTRIBUTION AND COMMITMENT
247113,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,I am resetting this to high priority only as per the maintainer judgement in comment 4.,task_subcomment,I am resetting this to high priority only as per the maintainer judgement in comment 4.,ACTION ON ISSUE
247107,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"jforrester: Should this really be highest priority (set in comment 7), or be
kept as high (as you did in comment 4)?",task_subcomment,"jforrester: Should this really be highest priority (set in comment 7), or be
kept as high (as you did in comment 4)?",TASK PROGRESS
247101,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"jforrester: Should this really be highest priority (set in comment 7), or be kept as high (as you did in comment 4)?",task_subcomment,"jforrester: Should this really be highest priority (set in comment 7), or be kept as high (as you did in comment 4)?",TASK PROGRESS
247094,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"(In reply to comment #2)
> Unless somebody has a better idea, we should probably implement toggling
> 'display' in JavaScript.

If the ca-action dropdown is the only exposed UI problem, perhaps the ca-action dropdown buttons could have a higher z-index, as a temporary fix at least?

(In reply to comment #5)
> So I was right that VE is *pushed* by the Wikimedia Foundation:
> https://bugzilla.wikimedia.org/show_activity.cgi?id=52659

It certainly is. While this regression outside of VisualEditor codebase is regrettable, and hopefully will be fixed soon, the VE team have pushed lots of great JS into core, and fixed bugs like bug 38081 which will benefit Wikimedia Commons.

I have bumped the importance up (but not wedded to it) as it is a regression caused by VE and affecting non-VE environments, and was reported two months ago, and the code change causing it was deployed in July.

In addition to impacting sysops with three ca-actions, it also affects non-sysops on every wiki, although not as pronounced.  Non sysops only have the the 'Move' button in the ca-action dropdown of Vector, and it is partially inaccessible.  If the user slowly moves their mouse cursor down into the dropdown, they can click the move icon if the click on the first few pixels above the word 'Move' - if they continue going down so that their mouse cursor hovers over the word 'Move', the drop down disappears.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE

If the ca-action dropdown is the only exposed UI problem, perhaps the ca-action dropdown buttons could have a higher z-index, as a temporary fix at least?

(In reply to comment #5)
QUOTE
QUOTE

It certainly is. While this regression outside of VisualEditor codebase is regrettable, and hopefully will be fixed soon, the VE team have pushed lots of great JS into core, and fixed bugs like bug 38081 which will benefit Wikimedia Commons.

I have bumped the importance up (but not wedded to it) as it is a regression caused by VE and affecting non-VE environments, and was reported two months ago, and the code change causing it was deployed in July.

In addition to impacting sysops with three ca-actions, it also affects non-sysops on every wiki, although not as pronounced.  Non sysops only have the the 'Move' button in the ca-action dropdown of Vector, and it is partially inaccessible.  If the user slowly moves their mouse cursor down into the dropdown, they can click the move icon if the click on the first few pixels above the word 'Move' - if they continue going down so that their mouse cursor hovers over the word 'Move', the drop down disappears.",BUG REPRODUCTION
247087,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"(In reply to comment #5)
> So I was right that VE is *pushed* by the Wikimedia Foundation:
> https://bugzilla.wikimedia.org/show_activity.cgi?id=52659

I'm confused. What are you saying?",task_subcomment,"(In reply to comment #5)
QUOTE
QUOTE

I'm confused. What are you saying?",ACTION ON ISSUE
247081,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,So I was right that VE is *pushed* by the Wikimedia Foundation: https://bugzilla.wikimedia.org/show_activity.cgi?id=52659,task_subcomment,So I was right that VE is *pushed* by the Wikimedia Foundation: URL,ACTION ON ISSUE
247076,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"From bug 55457 comment 0:

| 1. Trigger a notification
| 2. Click on the notification to dismiss it
| 3. The notification area (
    ) is now empty, but
| still obscures a narrow strip in the top right corner:
| 
| > $('#mw-notification-area').outerHeight()
| 12
| > $('#mw-notification-area').outerWidth()
| 269
| > $('#mw-notification-area').position()
| Object {top: 89.59375, left: 1251.203125}
| > $('#mw-notification-area').css('z-index')
| ""10000""
| 
| This is a problem because the div steals events and mouse interaction from the
| UI elements below it. For instance, in VisualEditor:
| 1. Open a page in VE
| 2. Type '[['. The wikitext warning appears
| 3. Click the warning to dismiss it
| 4. Reveal #mw-notification-area in the inspector and observe how it's on top
|    of part of the save button
| 5. Very carefully move the mouse over the save button, and you'll notice a
|    small (12px tall) area where mouse pointer is a normal pointer instead of a
|    hand. Clicking in this area does not press the save button.",task_subcomment,"From bug 55457 comment 0:

| 1. Trigger a notification
| 2. Click on the notification to dismiss it
| 3. The notification area (
    ) is now empty, but
| still obscures a narrow strip in the top right corner:
| 
| > $('#mw-notification-area').outerHeight()
| 12
| > $('#mw-notification-area').outerWidth()
| 269
| > $('#mw-notification-area').position()
| Object {top: 89.59375, left: 1251.203125}
| > $('#mw-notification-area').css('z-index')
| ""10000""
| 
| This is a problem because the div steals events and mouse interaction from the
| UI elements below it. For instance, in VisualEditor:
| 1. Open a page in VE
| 2. Type '[['. The wikitext warning appears
| 3. Click the warning to dismiss it
| 4. Reveal #mw-notification-area in the inspector and observe how it's on top
|    of part of the save button
| 5. Very carefully move the mouse over the save button, and you'll notice a
|    small (12px tall) area where mouse pointer is a normal pointer instead of a
|    hand. Clicking in this area does not press the save button.",BUG REPRODUCTION
247068,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,*** Bug 55457 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 55457 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
247060,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"The culprit is this line:
	padding: 1em 1em 0 0;
in mediawiki.notification.css. It causes .mw-notification-area to have a non-zero height and thus cover other elements, like the dropdown.

There are two obvious ways to fix it which don't work:

* Change the padding to margin. This causes the notifications to ""jump"" slightly when scrolling, as detailed in commit message of https://gerrit.wikimedia.org/r/#/c/75614/

* Add .mw-notification-area:empty { display: none; }. This doesn't work on IE<9 and other old browsers. [http://caniuse.com/#feat=css-sel3]

Unless somebody has a better idea, we should probably implement toggling 'display' in JavaScript.",task_subcomment,"The culprit is this line:
	padding: 1em 1em 0 0;
in mediawiki.notification.css. It causes .mw-notification-area to have a non-zero height and thus cover other elements, like the dropdown.

There are two obvious ways to fix it which don't work:

* Change the padding to margin. This causes the notifications to ""jump"" slightly when scrolling, as detailed in commit message of URL

* Add .mw-notification-area:empty { display: none; }. This doesn't work on IE<9 and other old browsers. [URL

Unless somebody has a better idea, we should probably implement toggling 'display' in JavaScript.",SOLUTION DISCUSSION
247052,[Regression] mediawiki.notification: Notification area remains visible when empty and steals pointer events,"Created attachment 13078
Screenshot FF, vector skin, mediawiki, mw-notify

I suppose this regression was introduced by fixing https://bugzilla.wikimedia.org/show_bug.cgi?id=50870
- When I test locally (codebase about 4 weeks old), the menu/dropdown does not close unexpectedly.

**Attached**: {F11623}",task_subcomment,"Created attachment 13078
Screenshot FF, vector skin, mediawiki, mw-notify

I suppose this regression was introduced by fixing URL
- When I test locally (codebase about 4 weeks old), the menu/dropdown does not close unexpectedly.

**Attached**: {F11623}",BUG REPRODUCTION
54638,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"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 '
    Life and career
    ' to '
    Life and careeer
    '
$ 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
    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.{{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]]}} 
-| 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'''[http://www.mlive.com/entertainment/saginaw/index.ssf/2008/08/ravensymone_steps_out_of_chara.html], (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]]'' 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]].[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. 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.[{{BillboardURLbyName|artist=raven-symoné|chart=Billboard 200}} Raven-Symoné]. Billboard.com. Retrieved 2012-05-19. 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,[http://blog.vh1.com/2012-12-02/and-the-1-greatest-kid-star-of-all-time-is/ Greatest Kid Star Of All Time] and ranked number one on ''Loop21''{{'s}} ""10 Richest Black Actresses Under 40"" list.[http://www.loop21.com/entertainment/10-richest-black-actresses-under-40 10 Richest Black Actresses Under 40]
 
-==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]] http://www.tv.com/people/raven-symone/http://xfinity.comcast.net/slideshow/entertainment-aachildactors/3/http://ethnicelebs.com/raven-symonehttp://www.imdb.com/name/nm0712368/biohttp://www.nndb.com/people/017/000103705/ and [[Native Americans in the United States|Native American]] ancestry. At age three, her family moved to [[Ossining (village), New York|Ossining, New York]] where she attended Park School.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.[http://ftp.rootsweb.com/pub/usgenweb/la/winn/bios/sym1569.txt Rootsweb.com]{{Dead link|date=May 2010}} 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",task_description,"At URL , 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 'URL -O originalHTML
$ wget 'URL -O originalWikitext
$ cp originalHTML editedHTML
$ vi editedHTML   # Change '
    Life and career
    ' to '
    Life and careeer
    '
$ 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
    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.{{cite web |url=URL Symone:Biography on MSN |accessdate=2008-07-15 |year=2008 |publisher=[[MSN]]}} 
-| 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         = [URL 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'''[URL (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]]'' 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]].[URL That's What Little Girls Are Made Of – Raven-Symoné]. Billboard.com. Retrieved 2012-05-19. 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.[{{BillboardURLbyName|artist=raven-symoné|chart=Billboard 200}} Raven-Symoné]. Billboard.com. Retrieved 2012-05-19. 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,[URL Greatest Kid Star Of All Time] and ranked number one on ''Loop21''{{'s}} ""10 Richest Black Actresses Under 40"" list.[URL 10 Richest Black Actresses Under 40]
 
-==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]] URL name=""imdb"">URL and [[Native Americans in the United States|Native American]] ancestry. At age three, her family moved to [[Ossining (village), New York|Ossining, New York]] where she attended Park School.Charlotte Moore (January 25, 2004). [URL Raven takes flight]{{dead link|date=September 2011}} PE.com.[URL Rootsweb.com]{{Dead link|date=May 2010}} 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",MOTIVATION
245979,Selser regression: pages with templates that generate tables and foster content out of the table are broken,Cache is now purged.  I tested on http://en.wikipedia.org/wiki/Crayon_Shin-chan (another page that had been reported with the bug) and verified fixed.,task_subcomment,Cache is now purged.  I tested on URL (another page that had been reported with the bug) and verified fixed.,TASK PROGRESS
245973,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"Fix deployed -- cache is not yet purged, but on purge tomorrow, this will be fixed.",task_subcomment,"Fix deployed -- cache is not yet purged, but on purge tomorrow, this will be fixed.",ACTION ON ISSUE
245966,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"Change 78242 merged by jenkins-bot:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

https://gerrit.wikimedia.org/r/78242",task_subcomment,"Change 78242 merged by jenkins-bot:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

GERRIT_URL",ACTION ON ISSUE
245956,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"Change 78242 had a related patch set uploaded by Subramanya Sastry:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

https://gerrit.wikimedia.org/r/78242",task_subcomment,"Change 78242 had a related patch set uploaded by Subramanya Sastry:
(Bug 52638) Fix selser regression introduced by fix for bug 51217

GERRIT_URL",ACTION ON ISSUE
245949,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"Reduced test case on which the problem can be reproduced:

{|
{{echo|a}}
|-
|x
}}

This is a selser regression introduced by a fix for bug 51217.

A fix will be in shortly.",task_subcomment,"Reduced test case on which the problem can be reproduced:

{|
{{echo|a}}
|-
|x
}}

This is a selser regression introduced by a fix for bug 51217.

A fix will be in shortly.",BUG REPRODUCTION
245942,Selser regression: pages with templates that generate tables and foster content out of the table are broken,"Confirmed. 

It is not a double-closed infobox.  It is an infobox within an infobox.  Although, I have gone through a number of these scenarios of infoboxes within infoboxes earlier and handled them in our regular serializer ... and confirmed that normal WTS (wt serializer) can handle it.  Now examining what gives selser the fits.

Thanks for the thorough testing and a way to reproduce it.  Will find a reduced test case and proceed.",task_subcomment,"Confirmed. 

It is not a double-closed infobox.  It is an infobox within an infobox.  Although, I have gone through a number of these scenarios of infoboxes within infoboxes earlier and handled them in our regular serializer ... and confirmed that normal WTS (wt serializer) can handle it.  Now examining what gives selser the fits.

Thanks for the thorough testing and a way to reproduce it.  Will find a reduced test case and proceed.",SOLUTION DISCUSSION
54596,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"**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",task_description,"**Author:** CODE

**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**:
URL",BUG REPRODUCTION
243461,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"

*** This bug has been marked as a duplicate of bug 51013 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 51013 ***",ACTION ON ISSUE
243457,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"This is because VisualEditor relies on MediaWiki's search system to work out what pages exist, and the search engine ignores short strings as not worth bothering with.

We could theoretically fix this in VisualEditor with a hack, but fixing search would be a better solution.",task_subcomment,"This is because VisualEditor relies on MediaWiki's search system to work out what pages exist, and the search engine ignores short strings as not worth bothering with.

We could theoretically fix this in VisualEditor with a hack, but fixing search would be a better solution.",SOLUTION DISCUSSION
243453,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,*** Bug 53547 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53547 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
243450,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"Indeed very, very odd. I've adjusted the bug summary to reflect the discovered behaviour. It is almost certainly unrelated to redirects though.",task_subcomment,"Indeed very, very odd. I've adjusted the bug summary to reflect the discovered behaviour. It is almost certainly unrelated to redirects though.",BUG REPRODUCTION
243446,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"**sandrobt.wiki** wrote:

Another surprising case is ""Cara"" on it.wiki. It exists and it is not a redirect but is not recognized as existent (neither writing ""Cara"" nor ""cara""), and ""CARA"" doesn't exist at all. 
So I guess this is not (only) related with redirects and it definitely appears also with pages with more than one character.",task_subcomment,"**sandrobt.wiki** wrote:

Another surprising case is ""Cara"" on it.wiki. It exists and it is not a redirect but is not recognized as existent (neither writing ""Cara"" nor ""cara""), and ""CARA"" doesn't exist at all. 
So I guess this is not (only) related with redirects and it definitely appears also with pages with more than one character.",INVESTIGATION AND EXPLORATION
243441,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"Hmm, not necessarily as simple as that as it recognises [[User:ABC]] and [[user:APL]]. It recognises both [[User:BBX]] and [[User:Bbx]] which are different pages and different users (the former Irish the latter a Finland-Swede).

It doesn't recognise [[User:Jim]] but that is a redirect to [[User:Jim (usurped)]].

It does recognise [[User:RVJ]], [[User:ZzZ]] and [[User:PQ3]]. 

I'm stumped!",task_subcomment,"Hmm, not necessarily as simple as that as it recognises [[User:ABC]] and [[user:APL]]. It recognises both [[User:BBX]] and [[User:Bbx]] which are different pages and different users (the former Irish the latter a Finland-Swede).

It doesn't recognise [[User:Jim]] but that is a redirect to [[User:Jim (usurped)]].

It does recognise [[User:RVJ]], [[User:ZzZ]] and [[User:PQ3]]. 

I'm stumped!",INVESTIGATION AND EXPLORATION
243436,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"(edit conflict)
Actually assuming that what happens in the user: namespace matches what happens in the article namespace then it is to do with the presence of a redirect. [[User:Rob]] exists but no pages (redirects or otherwise) exist for other capitalisations of those three letters. [[User:Rob]] does appear in the list of suggestions. Now whether that is this bug or bug 50898 I haven't got a clue, so I'll comment there as well.

(new text)
So it appears that it might be capitalisation related rather than redirect related - it works with sentence case Rob but not allcaps AB and FRA.",task_subcomment,"(edit conflict)
Actually assuming that what happens in the user: namespace matches what happens in the article namespace then it is to do with the presence of a redirect. [[User:Rob]] exists but no pages (redirects or otherwise) exist for other capitalisations of those three letters. [[User:Rob]] does appear in the list of suggestions. Now whether that is this bug or bug 50898 I haven't got a clue, so I'll comment there as well.

(new text)
So it appears that it might be capitalisation related rather than redirect related - it works with sentence case Rob but not allcaps AB and FRA.",INVESTIGATION AND EXPLORATION
243429,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"**sandrobt.wiki** wrote:

> Hmm, although redirects do exist at Ab and Fra which is probably confusing
> the
> issue. I think all TLAs exist as redirects or articles in uppercase and
> titlecase form so I don't know how to test this.

Also User:AB and User:FRA erroneously appear as non-existing (and user:Ab and User:Fra don't exist).",task_subcomment,"**sandrobt.wiki** wrote:

QUOTE
QUOTE
QUOTE
QUOTE

Also User:AB and User:FRA erroneously appear as non-existing (and user:Ab and User:Fra don't exist).",SOLUTION USAGE
243424,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"

(In reply to comment #3)
> What about ""AB"" or ""FRA""? Those are not redirects. Maybe ""single character
> titles"" is not accurate enough.

Hmm, although redirects do exist at Ab and Fra which is probably confusing the issue. I think all TLAs exist as redirects or articles in uppercase and titlecase form so I don't know how to test this.

(In reply to comment #4)
> Created attachment 13081 [details]
> Link dialog doesn't recognise that existence of single-character page names

This shows that it is the page name (excluding namespace) not the full page name (including namespace) that matters as [[User:A]] (which exists) is not recognised.

**Attached**: {F11470}",task_subcomment,"

(In reply to comment #3)
QUOTE
QUOTE

Hmm, although redirects do exist at Ab and Fra which is probably confusing the issue. I think all TLAs exist as redirects or articles in uppercase and titlecase form so I don't know how to test this.

(In reply to comment #4)
QUOTE
QUOTE

This shows that it is the page name (excluding namespace) not the full page name (including namespace) that matters as [[User:A]] (which exists) is not recognised.

**Attached**: {F11470}",ACTION ON ISSUE
243420,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"Created attachment 13081
Link dialog doesn't recognise that existence of single-character page names

**Attached**: {F11470}",task_subcomment,"Created attachment 13081
Link dialog doesn't recognise that existence of single-character page names

**Attached**: {F11470}",BUG REPRODUCTION
243417,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"**sandrobt.wiki** wrote:

What about ""AB"" or ""FRA""? Those are not redirects. Maybe ""single character titles"" is not accurate enough.",task_subcomment,"**sandrobt.wiki** wrote:

What about ""AB"" or ""FRA""? Those are not redirects. Maybe ""single character titles"" is not accurate enough.",SOLUTION DISCUSSION
243414,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"Redirects not showing in the list are due to case sensitivity issues, see bug 50898 

Single character titles are never recognised, whether they are articles (e.g [[A]], [[Ä]]) or redirects, so I'm boldly refocusing this bug solely on this issue.",task_subcomment,"Redirects not showing in the list are due to case sensitivity issues, see bug 50898 

Single character titles are never recognised, whether they are articles (e.g [[A]], [[Ä]]) or redirects, so I'm boldly refocusing this bug solely on this issue.",BUG REPRODUCTION
243410,VisualEditor: Some pages with short titles (incl all with single character titles) are not recognised as existing pages in the link box,"**sandrobt.wiki** wrote:

Maybe writing ""short"" in the title was a mistake (but anyway this bug appears more often with short titles): SEGA, FIDO and GOOGLE also are not recognized as existing pages. However these are all redirects, so perhaps this is another known independent issue?",task_subcomment,"**sandrobt.wiki** wrote:

Maybe writing ""short"" in the title was a mistake (but anyway this bug appears more often with short titles): SEGA, FIDO and GOOGLE also are not recognized as existing pages. However these are all redirects, so perhaps this is another known independent issue?",BUG REPRODUCTION
54561,VisualEditor: Dragging mouse clicks VE buttons upon release,"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",task_description,"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",BUG REPRODUCTION
241301,VisualEditor: Dragging mouse clicks VE buttons upon release,"I cant reproduce any combination supported on Linux, or Firefox/Windows/monobook.",task_subcomment,"I cant reproduce any combination supported on Linux, or Firefox/Windows/monobook.",BUG REPRODUCTION
241295,VisualEditor: Dragging mouse clicks VE buttons upon release,"Does this still occur for anyone?
Using the version of VE currently live on en.wp in Firefox 24/monobook/Linux I can't reproduce this at all, not even the way I could in comment 2",task_subcomment,"Does this still occur for anyone?
Using the version of VE currently live on en.wp in Firefox 24/monobook/Linux I can't reproduce this at all, not even the way I could in comment 2",BUG REPRODUCTION
241290,VisualEditor: Dragging mouse clicks VE buttons upon release,"After clarification I have done more testing and found that I can't reproduce this when any text is selected (including text in a table), but I can if the selection is exclusively an image or template (including an image in table).

Further Cryptic C62 uses Windows Vista not Windows 7.",task_subcomment,"After clarification I have done more testing and found that I can't reproduce this when any text is selected (including text in a table), but I can if the selection is exclusively an image or template (including an image in table).

Further Cryptic C62 uses Windows Vista not Windows 7.",BUG REPRODUCTION
241286,VisualEditor: Dragging mouse clicks VE buttons upon release,"Cryptic stated in the original bug report ""Some testing shows that this is universal (Firefox/Vector, Opera/Vector, Safari/Monobook)"". From other bug reports of theirs I believe that they run Windows 7.

I have not been able to reproduce this in Firefox 22 on Xubuntu linux using Monobook. The toolbar button depresses as if it were going to apply its function, but nothing actually happens.",task_subcomment,"Cryptic stated in the original bug report ""Some testing shows that this is universal (Firefox/Vector, Opera/Vector, Safari/Monobook)"". From other bug reports of theirs I believe that they run Windows 7.

I have not been able to reproduce this in Firefox 22 on Xubuntu linux using Monobook. The toolbar button depresses as if it were going to apply its function, but nothing actually happens.",BUG REPRODUCTION
54526,VisualEditor: Inspectors should not display below visible page area,"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",task_description,"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",SOLUTION DISCUSSION
239212,VisualEditor: Inspectors should not display below visible page area,"Change 163228 merged by jenkins-bot:
DesktopContext: Ensure that inspectors/menus are fully visible when created

https://gerrit.wikimedia.org/r/163228",task_subcomment,"Change 163228 merged by jenkins-bot:
DesktopContext: Ensure that inspectors/menus are fully visible when created

GERRIT_URL",SOLUTION USAGE
239205,VisualEditor: Inspectors should not display below visible page area,"(This only affects inspectors, and they're a VE feature; moving.)",task_subcomment,"(This only affects inspectors, and they're a VE feature; moving.)",ACTION ON ISSUE
239198,VisualEditor: Inspectors should not display below visible page area,"Change 163280 merged by jenkins-bot:
PopupWidget: Make $element not be a 0x0 box

https://gerrit.wikimedia.org/r/163280",task_subcomment,"Change 163280 merged by jenkins-bot:
PopupWidget: Make $element not be a 0x0 box

GERRIT_URL",ACTION ON ISSUE
239192,VisualEditor: Inspectors should not display below visible page area,"Change 163280 had a related patch set uploaded by Bartosz Dziewoński:
PopupWidget: Make $element not be a 0x0 box

https://gerrit.wikimedia.org/r/163280",task_subcomment,"Change 163280 had a related patch set uploaded by Bartosz Dziewoński:
PopupWidget: Make $element not be a 0x0 box

GERRIT_URL",ACTION ON ISSUE
239187,VisualEditor: Inspectors should not display below visible page area,"Change 163228 had a related patch set uploaded by Bartosz Dziewoński:
[WIP] DesktopContext: Ensure that inspectors/menus are fully visible when created

https://gerrit.wikimedia.org/r/163228",task_subcomment,"Change 163228 had a related patch set uploaded by Bartosz Dziewoński:
[WIP] DesktopContext: Ensure that inspectors/menus are fully visible when created

GERRIT_URL",TASK PROGRESS
239182,VisualEditor: Inspectors should not display below visible page area,This is fixed for dialogs in gerrit 139550. It's not yet fixed for inspectors (which I suppose should scroll-into-view?).,task_subcomment,This is fixed for dialogs in gerrit 139550. It's not yet fixed for inspectors (which I suppose should scroll-into-view?).,SOLUTION USAGE
54517,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"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",task_description,"At URL 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**: URL",BUG REPRODUCTION
238713,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"Change 114000 merged by jenkins-bot:
Fix ce#getOffset when cursor is to the left of an annotation.

https://gerrit.wikimedia.org/r/114000",task_subcomment,"Change 114000 merged by jenkins-bot:
Fix ce#getOffset when cursor is to the left of an annotation.

GERRIT_URL",SOLUTION USAGE
238705,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"Change 114000 had a related patch set uploaded by Esanders:
Fix ce#getOffset when cursor is to the left of an annotation.

https://gerrit.wikimedia.org/r/114000",task_subcomment,"Change 114000 had a related patch set uploaded by Esanders:
Fix ce#getOffset when cursor is to the left of an annotation.

GERRIT_URL",TASK PROGRESS
238698,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"(In reply to Ed Sanders from comment #3)
> Can't reproduce in FF 27. Can someone else?

Yes.",task_subcomment,"(In reply to Ed Sanders from comment #3)
QUOTE

Yes.",SOLUTION DISCUSSION
238692,VisualEditor: Cannot apply annotations to link in specific case in Firefox,Can't reproduce in FF 27. Can someone else?,task_subcomment,Can't reproduce in FF 27. Can someone else?,BUG REPRODUCTION
238686,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"Confirmed. Very odd. Note that making the selection broader (e.g. a character either side of the link) lets you make it bold/remove italics/etc.

Sorry for very slow triage.",task_subcomment,"Confirmed. Very odd. Note that making the selection broader (e.g. a character either side of the link) lets you make it bold/remove italics/etc.

Sorry for very slow triage.",ACTION ON ISSUE
238681,VisualEditor: Cannot apply annotations to link in specific case in Firefox,"Note, the way I tried to unitalicize was by double-clicking the name (so it's all highlighted), then clicking the toolbar italics icon (which showed as enabled before I clicked).",task_subcomment,"Note, the way I tried to unitalicize was by double-clicking the name (so it's all highlighted), then clicking the toolbar italics icon (which showed as enabled before I clicked).",SOLUTION USAGE
54504,VisualEditor: Top bar not staying at top,"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",task_description,"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) URL 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) URL that is, throw some text on an existing link, you'll lose the toolbar as well.
Thanks.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL
URL",BUG REPRODUCTION
237954,VisualEditor: Top bar not staying at top,"(In reply to comment #4)
> I can't reproduce this now, is anyone else still seeing it or can we presume
> that bug 52441 did fix the issue?

My test file doesn't show the problem any more, certainly: seems to be fixed, thanks.",task_subcomment,"(In reply to comment #4)
QUOTE
QUOTE

My test file doesn't show the problem any more, certainly: seems to be fixed, thanks.",SOLUTION USAGE
237946,VisualEditor: Top bar not staying at top,"I can't reproduce this now, is anyone else still seeing it or can we presume that bug 52441 did fix the issue?",task_subcomment,"I can't reproduce this now, is anyone else still seeing it or can we presume that bug 52441 did fix the issue?",BUG REPRODUCTION
237938,VisualEditor: Top bar not staying at top,Will the fix of Bug 52441 (awaiting deployment) also solve this?,task_subcomment,Will the fix of Bug 52441 (awaiting deployment) also solve this?,SOLUTION DISCUSSION
237934,VisualEditor: Top bar not staying at top,"Compare http://en.wikipedia.org/wiki/User:PamD/sandbox_for_VE/test2 (top bar disappears) http://en.wikipedia.org/wiki/User:PamD/sandbox_for_VE/test3 (no problem): only difference is addition of ""a "" before the linked text on first line. No other links, templates, complexities, in the files.",task_subcomment,"Compare URL (top bar disappears) URL (no problem): only difference is addition of ""a "" before the linked text on first line. No other links, templates, complexities, in the files.",BUG REPRODUCTION
237926,VisualEditor: Top bar not staying at top,"http://en.wikipedia.org/w/index.php?title=User%3APamD%2Fsandbox_for_VE%2Ftest1&diff=567087060&oldid=567086998  Unlinking the first word seems to have solved the problem. Given that most dab pages with titles in ""Foo (disambiguation)"" start off with a bolded link to Foo, this is a problem.",task_subcomment,"URL  Unlinking the first word seems to have solved the problem. Given that most dab pages with titles in ""Foo (disambiguation)"" start off with a bolded link to Foo, this is a problem.",BUG REPRODUCTION
54499,VisualEditor: Protected node css with * selector breaks some template layouts,"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",task_description,"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**:
URL",SOLUTION USAGE
237587,VisualEditor: Protected node css with * selector breaks some template layouts,"Change 130823 merged by jenkins-bot:
Remove '*' selector for protected nodes

https://gerrit.wikimedia.org/r/130823",task_subcomment,"Change 130823 merged by jenkins-bot:
Remove '*' selector for protected nodes

GERRIT_URL",ACTION ON ISSUE
237577,VisualEditor: Protected node css with * selector breaks some template layouts,"Created attachment 15263
Screenshot of problem and patched version

**Attached**: {F11282}",task_subcomment,"Created attachment 15263
Screenshot of problem and patched version

**Attached**: {F11282}",BUG REPRODUCTION
237569,VisualEditor: Protected node css with * selector breaks some template layouts,"Change 130823 had a related patch set uploaded by Esanders:
Remove '*' selector for protected nodes

https://gerrit.wikimedia.org/r/130823",task_subcomment,"Change 130823 had a related patch set uploaded by Esanders:
Remove '*' selector for protected nodes

GERRIT_URL",ACTION ON ISSUE
54490,VisualEditor: Reference fails to display in reference list on init or change (but appears if you add a new use of it),"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",task_description,"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:

URL 1 out of 55

URL 0 out of 1

URL 5 out of 15

URL 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:

URL

--------------------------
**Version**: unspecified
**Severity**: major",BUG REPRODUCTION
236998,VisualEditor: Reference fails to display in reference list on init or change (but appears if you add a new use of it),This was fixed by https://gerrit.wikimedia.org/r/#/c/77346/1 . Apparently yet to deploy on de.wiki.,task_subcomment,This was fixed by URL . Apparently yet to deploy on de.wiki.,SOLUTION USAGE
236988,VisualEditor: Reference fails to display in reference list on init or change (but appears if you add a new use of it),This looks like a bug we fixed recently with unnamed references. What version is deployed to de.wiki?,task_subcomment,This looks like a bug we fixed recently with unnamed references. What version is deployed to de.wiki?,BUG REPRODUCTION
236980,VisualEditor: Reference fails to display in reference list on init or change (but appears if you add a new use of it),Does de.wp have more than one method of displaying references (equivalent to en's {{reflist}} and )? If so then this could be related to bug 52371,task_subcomment,Does de.wp have more than one method of displaying references (equivalent to en's {{reflist}} and )? If so then this could be related to bug 52371,SOLUTION DISCUSSION
54483,"TemplateData: Fix ""TypeError: Cannot read property 'content' of undefined"" (when applying template changes)","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",task_description,"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",BUG REPRODUCTION
236608,"TemplateData: Fix ""TypeError: Cannot read property 'content' of undefined"" (when applying template changes)","Change 77460 merged by jenkins-bot:
ve.ce.MWTransclusionNode: Check for API errors

https://gerrit.wikimedia.org/r/77460",task_subcomment,"Change 77460 merged by jenkins-bot:
ve.ce.MWTransclusionNode: Check for API errors

GERRIT_URL",TASK PROGRESS
236600,"TemplateData: Fix ""TypeError: Cannot read property 'content' of undefined"" (when applying template changes)","Change 77460 had a related patch set uploaded by Krinkle:
ve.ce.MWTransclusionNode: Check for API errors

https://gerrit.wikimedia.org/r/77460",task_subcomment,"Change 77460 had a related patch set uploaded by Krinkle:
ve.ce.MWTransclusionNode: Check for API errors

GERRIT_URL",ACTION ON ISSUE
54477,VisualEditor: Data model should be able to default between equivalent annotations,"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",task_description,"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",SOLUTION DISCUSSION
236355,VisualEditor: Data model should be able to default between equivalent annotations,"Change 78204 merged by jenkins-bot:
Generic support for multiple tags in TextStyleAnnotation

https://gerrit.wikimedia.org/r/78204",task_subcomment,"Change 78204 merged by jenkins-bot:
Generic support for multiple tags in TextStyleAnnotation

GERRIT_URL",ACTION ON ISSUE
236349,VisualEditor: Data model should be able to default between equivalent annotations,"Change 78204 had a related patch set uploaded by Catrope:
Generic support for multiple tags in TextStyleAnnotation

https://gerrit.wikimedia.org/r/78204",task_subcomment,"Change 78204 had a related patch set uploaded by Catrope:
Generic support for multiple tags in TextStyleAnnotation

GERRIT_URL",ACTION ON ISSUE
236343,VisualEditor: Data model should be able to default between equivalent annotations,code/tt duplicate of bug 52352,task_subcomment,code/tt duplicate of bug 52352,BUG REPRODUCTION
54476,Update tours for new edit tab selectors,"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",task_description,"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",SOLUTION USAGE
236298,Update tours for new edit tab selectors,"Change 78026 merged by jenkins-bot:
Update VE section edit selector

https://gerrit.wikimedia.org/r/78026",task_subcomment,"Change 78026 merged by jenkins-bot:
Update VE section edit selector

GERRIT_URL",ACTION ON ISSUE
236295,Update tours for new edit tab selectors,"Change 78026 had a related patch set uploaded by Mattflaschen:
Update VE section edit selector

https://gerrit.wikimedia.org/r/78026",task_subcomment,"Change 78026 had a related patch set uploaded by Mattflaschen:
Update VE section edit selector

GERRIT_URL",ACTION ON ISSUE
236290,Update tours for new edit tab selectors,"Change 77387 merged by jenkins-bot:
Update to match new VisualEditor edit tab selector

https://gerrit.wikimedia.org/r/77387",task_subcomment,"Change 77387 merged by jenkins-bot:
Update to match new VisualEditor edit tab selector

GERRIT_URL",ACTION ON ISSUE
236285,Update tours for new edit tab selectors,"Change 77387 had a related patch set uploaded by Mattflaschen:
Update to match new VisualEditor edit tab selector

https://gerrit.wikimedia.org/r/77387",task_subcomment,"Change 77387 had a related patch set uploaded by Mattflaschen:
Update to match new VisualEditor edit tab selector

GERRIT_URL",TASK PROGRESS
236279,Update tours for new edit tab selectors,"**swalling** wrote:

Yes, without this fixed I get the gettinstartedtasktoolbarve tour (meant for VE) pointing to edit source, not the new beta tab. 

Thankfully it's just missing some steps, not causing any visibly broken or confusing behavior.",task_subcomment,"**swalling** wrote:

Yes, without this fixed I get the gettinstartedtasktoolbarve tour (meant for VE) pointing to edit source, not the new beta tab. 

Thankfully it's just missing some steps, not causing any visibly broken or confusing behavior.",BUG REPRODUCTION
54475,VisualEditor:  User guide should open in a new tab/window,"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",task_description,"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",BUG REPRODUCTION
236240,VisualEditor:  User guide should open in a new tab/window,"Thanks for the reply, that is very useful to know.

Brevity is not my strong suit so I've refrained from making a change to it myself. I've asked for suggestions at [[WP:VE/F#User Manual should open in new tab/window]], feel free to opine.",task_subcomment,"Thanks for the reply, that is very useful to know.

Brevity is not my strong suit so I've refrained from making a change to it myself. I've asked for suggestions at [[WP:VE/F#User Manual should open in new tab/window]], feel free to opine.",ACTION ON ISSUE
236236,VisualEditor:  User guide should open in a new tab/window,"The text is controlled by https://en.wikipedia.org/wiki/MediaWiki:Visualeditor-help-label - but I'd counsel against putting a lot of text into it, as it may not look very good.",task_subcomment,"The text is controlled by URL - but I'd counsel against putting a lot of text into it, as it may not look very good.",SOLUTION USAGE
236233,VisualEditor:  User guide should open in a new tab/window,"Thanks for the super-quick fix.

As for the wait until deployment, would it be possible to add something like ""(hold CTRL while clicking this link to open it in a new window)"" before this goes live?
If not it's not worth doing anything, but if we can as an interim measure help some people that's better than nothing.",task_subcomment,"Thanks for the super-quick fix.

As for the wait until deployment, would it be possible to add something like ""(hold CTRL while clicking this link to open it in a new window)"" before this goes live?
If not it's not worth doing anything, but if we can as an interim measure help some people that's better than nothing.",SOLUTION USAGE
236231,VisualEditor:  User guide should open in a new tab/window,"Now fixed in the code; next scheduled deployment is not until 15 August, however. :-(",task_subcomment,"Now fixed in the code; next scheduled deployment is not until 15 August, however. :-(",ACTION ON ISSUE
236229,VisualEditor:  User guide should open in a new tab/window,"Change 77374 merged by jenkins-bot:
Make the link to the user guide open in a new window

https://gerrit.wikimedia.org/r/77374",task_subcomment,"Change 77374 merged by jenkins-bot:
Make the link to the user guide open in a new window

GERRIT_URL",ACTION ON ISSUE
236225,VisualEditor:  User guide should open in a new tab/window,"Change 77374 had a related patch set uploaded by Jforrester:
Make the link to the user guide open in a new window

https://gerrit.wikimedia.org/r/77374",task_subcomment,"Change 77374 had a related patch set uploaded by Jforrester:
Make the link to the user guide open in a new window

GERRIT_URL",ACTION ON ISSUE
236219,VisualEditor:  User guide should open in a new tab/window,Marking as high priority like similar bug 52093,task_subcomment,Marking as high priority like similar bug 52093,ACTION ON ISSUE
54463,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"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",task_description,"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",BUG REPRODUCTION
235622,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,Verified in production,task_subcomment,Verified in production,VERIFICATION
235618,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,Verified the fix in Betalabs,task_subcomment,Verified the fix in Betalabs,SOLUTION USAGE
235614,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133864 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133864",task_subcomment,"Change 133864 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

GERRIT_URL",SOLUTION USAGE
235610,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133864 had a related patch set uploaded by Jforrester:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133864",task_subcomment,"Change 133864 had a related patch set uploaded by Jforrester:
Hide 'no results found' once there's at least one result

GERRIT_URL",SOLUTION USAGE
235606,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133858 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133858",task_subcomment,"Change 133858 merged by jenkins-bot:
Hide 'no results found' once there's at least one result

GERRIT_URL",SOLUTION USAGE
235601,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133858 had a related patch set uploaded by Mooeypoo:
Hide 'no results found' once there's at least one result

https://gerrit.wikimedia.org/r/133858",task_subcomment,"Change 133858 had a related patch set uploaded by Mooeypoo:
Hide 'no results found' once there's at least one result

GERRIT_URL",SOLUTION USAGE
235598,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Created attachment 15419
Screenshot

**Attached**: {F11195}",task_subcomment,"Created attachment 15419
Screenshot

**Attached**: {F11195}",BUG REPRODUCTION
235592,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"The message ""No results found"" stays in the dialog even if user changed the search string and the matched images appear inside the dialog.See the screenshot attached",task_subcomment,"The message ""No results found"" stays in the dialog even if user changed the search string and the matched images appear inside the dialog.See the screenshot attached",BUG REPRODUCTION
235585,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133050 merged by jenkins-bot:
If no media is found display a message in media insert dialog

https://gerrit.wikimedia.org/r/133050",task_subcomment,"Change 133050 merged by jenkins-bot:
If no media is found display a message in media insert dialog

GERRIT_URL",ACTION ON ISSUE
235579,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Change 133050 had a related patch set uploaded by Mooeypoo:
If no media is found display a message in media insert dialog

https://gerrit.wikimedia.org/r/133050",task_subcomment,"Change 133050 had a related patch set uploaded by Mooeypoo:
If no media is found display a message in media insert dialog

GERRIT_URL",SOLUTION USAGE
235572,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"WhatamIdoing, there is a design that has not been implemented yet for the image dialog that allow quick access to users uploads, perhaps in the case of zero search results, we can automatically show that mode.",task_subcomment,"WhatamIdoing, there is a design that has not been implemented yet for the image dialog that allow quick access to users uploads, perhaps in the case of zero search results, we can automatically show that mode.",SOLUTION DISCUSSION
235565,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,*** Bug 60932 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 60932 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
235561,VisualEditor: Media insertion dialog should display a message if no media is found for the given search,"Given the fact that users often want to add the image that they just uploaded, and that Commons's search is fairly often taking a couple of days to ""notice"" that these images exist, the default message on wikis that use Commons should say something like ""No image was found.  If you just uploaded an image with this name, this may be due to the image not being indexed in Commons's search database yet.  Please try again in a couple of days.""

It might also be worth linking to a help page that describes limitations in the search protocol.  For example, it will find images if I give it the whole name (""2013AliceAndBob"") but not if I give it just the start of the name (""2013Alice"").",task_subcomment,"Given the fact that users often want to add the image that they just uploaded, and that Commons's search is fairly often taking a couple of days to ""notice"" that these images exist, the default message on wikis that use Commons should say something like ""No image was found.  If you just uploaded an image with this name, this may be due to the image not being indexed in Commons's search database yet.  Please try again in a couple of days.""

It might also be worth linking to a help page that describes limitations in the search protocol.  For example, it will find images if I give it the whole name (""2013AliceAndBob"") but not if I give it just the start of the name (""2013Alice"").",SOLUTION DISCUSSION
54460,VisualEditor:  Inserting media when text is selected should not overwrite text,"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",task_description,"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",BUG REPRODUCTION
235386,VisualEditor:  Inserting media when text is selected should not overwrite text,"Change 82463 merged by jenkins-bot:
Insert images after selection, not in place of it

https://gerrit.wikimedia.org/r/82463",task_subcomment,"Change 82463 merged by jenkins-bot:
Insert images after selection, not in place of it

GERRIT_URL",ACTION ON ISSUE
235380,VisualEditor:  Inserting media when text is selected should not overwrite text,"Change 82463 had a related patch set uploaded by Trevor Parscal:
Insert images after selection, not in place of it

https://gerrit.wikimedia.org/r/82463",task_subcomment,"Change 82463 had a related patch set uploaded by Trevor Parscal:
Insert images after selection, not in place of it

GERRIT_URL",SOLUTION USAGE
54441,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,"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",task_description,"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**:
URL",BUG REPRODUCTION
234329,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,*** Bug 52739 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52739 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
234323,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,*** Bug 52789 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52789 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
234316,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,*** Bug 52433 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52433 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
234310,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,*** Bug 52326 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52326 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
234304,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,"Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(",task_subcomment,"Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(",ACTION ON ISSUE
234297,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,"Change 77274 merged by jenkins-bot:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

https://gerrit.wikimedia.org/r/77274",task_subcomment,"Change 77274 merged by jenkins-bot:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

GERRIT_URL",SOLUTION USAGE
234287,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,"Change 77274 had a related patch set uploaded by Krinkle:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

https://gerrit.wikimedia.org/r/77274",task_subcomment,"Change 77274 had a related patch set uploaded by Krinkle:
ve.ui.Toolbar: Use closure instead of ve.bind for event handlers

GERRIT_URL",TASK PROGRESS
234279,VisualEditor: [Regression] Toolbar floating mode broken after opening an inspector,"After much debugging (filed the bug only now), I figured out what caused it:

The target toolbar continues to have toolbar.floatable === true. That never gets disabled by anything, so that's good.

What happens is that the toolbar inside the context menu, twice, gets called disableFloatable on. Though that is a separate instance, independent, there is 1 place where it effects global state unfortunately: the $window handlers.

The prototype is inherited by each instance, naturally, which means toolbarA.onWindowScroll === toolbarB.onWindowScroll. So when we pass them to $window.off to unbind by reference, it does exactly what you (now) expect, thus also breaking it for other toolbars.

However that's not what's happening, actually, because we (of course) want each toolbar to have the event bound to the exact instance of ve.ui.Toolbar, and we do so by using ve.bind.

Which means toolbarA.windowEvents.scroll is a unique closure, separate from toolbarB.windowEvents.scroll. That is what makes it work. So why does it fail?

Well, jQuery.proxy (=== ve.bind) is so nice for us that it tacks a guid property on the function reference to make sure that when binding a function to a scope, we can still identify it. This e.g. makes the following possible:

 1: $foo.on( 'scroll', $.proxy( myHandler ) );
 2: $foo.off( 'scroll', myHandler );
 3: // or alternatively, though useless:
 4: $foo.off( 'scroll', $.proxy( myHandler ) );

jQuery's event system uses this same guid (when present) to unbind a method.

So the first time we call ve.bind in a ve.ui.Toolbar construction, a guid is added to #onWindowScroll.. And the second time it just uses the same guid again (which makes line 4 above work). It does still make a new closure, so there's no problem with the second one being given a cached closure or something that refers to the first instance, nothing like that.

However we very much don't want this. We need each one to be unique not just by reference and context bound, but no shared guids.

Finally, why did this break only recently? Well, before 14343c7bf7 toolbar.$window was null by default and stayed that way until enableFloating was called. So the call to disableFloating for the context menu toolbar did nothing.

14343c7bf7 refactored the code to always need a toolbar.$window during initialisation, and for efficiency kept the instance around as to not create/destroy it each time.

So though 14343c7bf7 introduced the bug being more visible, the problem was already in the code. Both then and now, when enableFloating is called and then disableFloating, the disableFloating unbinds all window events for effectively all toolbars.


Also:
- During debugging I found that we're calling disableFloatable *twice* on the context menu toolbar (once when the inspector is opened and again when we close it). That should be optimised to one. Or better, don't call it at all since it is disabled by default.",task_subcomment,"After much debugging (filed the bug only now), I figured out what caused it:

The target toolbar continues to have toolbar.floatable === true. That never gets disabled by anything, so that's good.

What happens is that the toolbar inside the context menu, twice, gets called disableFloatable on. Though that is a separate instance, independent, there is 1 place where it effects global state unfortunately: the $window handlers.

The prototype is inherited by each instance, naturally, which means toolbarA.onWindowScroll === toolbarB.onWindowScroll. So when we pass them to $window.off to unbind by reference, it does exactly what you (now) expect, thus also breaking it for other toolbars.

However that's not what's happening, actually, because we (of course) want each toolbar to have the event bound to the exact instance of ve.ui.Toolbar, and we do so by using ve.bind.

Which means toolbarA.windowEvents.scroll is a unique closure, separate from toolbarB.windowEvents.scroll. That is what makes it work. So why does it fail?

Well, jQuery.proxy (=== ve.bind) is so nice for us that it tacks a guid property on the function reference to make sure that when binding a function to a scope, we can still identify it. This e.g. makes the following possible:

 1: $foo.on( 'scroll', $.proxy( myHandler ) );
 2: $foo.off( 'scroll', myHandler );
 3: // or alternatively, though useless:
 4: $foo.off( 'scroll', $.proxy( myHandler ) );

jQuery's event system uses this same guid (when present) to unbind a method.

So the first time we call ve.bind in a ve.ui.Toolbar construction, a guid is added to #onWindowScroll.. And the second time it just uses the same guid again (which makes line 4 above work). It does still make a new closure, so there's no problem with the second one being given a cached closure or something that refers to the first instance, nothing like that.

However we very much don't want this. We need each one to be unique not just by reference and context bound, but no shared guids.

Finally, why did this break only recently? Well, before 14343c7bf7 toolbar.$window was null by default and stayed that way until enableFloating was called. So the call to disableFloating for the context menu toolbar did nothing.

14343c7bf7 refactored the code to always need a toolbar.$window during initialisation, and for efficiency kept the instance around as to not create/destroy it each time.

So though 14343c7bf7 introduced the bug being more visible, the problem was already in the code. Both then and now, when enableFloating is called and then disableFloating, the disableFloating unbinds all window events for effectively all toolbars.


Also:
- During debugging I found that we're calling disableFloatable *twice* on the context menu toolbar (once when the inspector is opened and again when we close it). That should be optimised to one. Or better, don't call it at all since it is disabled by default.",SOLUTION DISCUSSION
54427,VisualEditor: references in image captions are not included in reflists,"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",task_description,"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**:
URL
URL
URL",BUG REPRODUCTION
233531,VisualEditor: references in image captions are not included in reflists,"Re-setting as FIXED, and have raised the regression as bug 57228.",task_subcomment,"Re-setting as FIXED, and have raised the regression as bug 57228.",ACTION ON ISSUE
233527,VisualEditor: references in image captions are not included in reflists,"<<[...] the references 20 and 21 in https://en.wikipedia.org/wiki/Baruch_Spinoza?veaction=edit which are in image captions disappear from the references list in VE and the numbering becomes discombobulated. Win7 FF 24.0 Monobook. --Atethnekos (Discussion, Contributions) 05:42, 12 November 2013 (UTC)>>.",task_subcomment,"<<[...] the references 20 and 21 in URL which are in image captions disappear from the references list in VE and the numbering becomes discombobulated. Win7 FF 24.0 Monobook. --Atethnekos (Discussion, Contributions) 05:42, 12 November 2013 (UTC)>>.",BUG REPRODUCTION
233523,VisualEditor: references in image captions are not included in reflists,"Change 77346 merged by jenkins-bot:
Only skip past empty keyedNodes sets if key exists

https://gerrit.wikimedia.org/r/77346",task_subcomment,"Change 77346 merged by jenkins-bot:
Only skip past empty keyedNodes sets if key exists

GERRIT_URL",ACTION ON ISSUE
233519,VisualEditor: references in image captions are not included in reflists,"Change 77346 had a related patch set uploaded by Esanders:
Only skip past empty keyedNodes sets if key exists

https://gerrit.wikimedia.org/r/77346",task_subcomment,"Change 77346 had a related patch set uploaded by Esanders:
Only skip past empty keyedNodes sets if key exists

GERRIT_URL",TASK PROGRESS
233516,VisualEditor: references in image captions are not included in reflists,"**kwwilliams** wrote:

52300 may also be related.",task_subcomment,"**kwwilliams** wrote:

52300 may also be related.",TASK PROGRESS
54372,VisualEditor: Using browser native interactive spell-check tool breaks in Firefox,"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",task_description,"At URL 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",BUG REPRODUCTION
255215,VisualEditor: Using browser native interactive spell-check tool breaks in Firefox,"

*** This bug has been marked as a duplicate of bug 50822 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 50822 ***",ACTION ON ISSUE
255205,VisualEditor: Using browser native interactive spell-check tool breaks in Firefox,"**crypticc62** wrote:

I've found that a similar problem occurs with Chrome on an iPad 3, though with very different results. In this environment, the spellcheck seems to work fine, but undo causes the original string to be appended to the new string, rather than replacing it.",task_subcomment,"**crypticc62** wrote:

I've found that a similar problem occurs with Chrome on an iPad 3, though with very different results. In this environment, the spellcheck seems to work fine, but undo causes the original string to be appended to the new string, rather than replacing it.",BUG REPRODUCTION
54366,VisualEditor: Make beta notice more prominent,"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",task_description,"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",SOLUTION DISCUSSION
254893,VisualEditor: Make beta notice more prominent,"We've now made a modal dialog pop up warning the user about the beta status of VisualEditor, and labelled VisualEditor as ""beta"" on its edit tab (and the edit section links that launch it).

I'm going to presumptively (;-)) mark this as ""fixed"", but please re-open if you think we should do more.",task_subcomment,"We've now made a modal dialog pop up warning the user about the beta status of VisualEditor, and labelled VisualEditor as ""beta"" on its edit tab (and the edit section links that launch it).

I'm going to presumptively (;-)) mark this as ""fixed"", but please re-open if you think we should do more.",ACTION ON ISSUE
54355,"VisualEditor (and possibly other beta tools) need an exposed, easy-to-use on/off switch","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",task_description,"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**:
URL",BUG REPRODUCTION
254366,"VisualEditor (and possibly other beta tools) need an exposed, easy-to-use on/off switch",BetaFeatures is in place for this now.,task_subcomment,BetaFeatures is in place for this now.,SOLUTION DISCUSSION
254364,"VisualEditor (and possibly other beta tools) need an exposed, easy-to-use on/off switch","Hi MZMcBride, a desktop framework for beta testing features is already underway[1}, although it was originally envisioned for smaller experiments we can certainly think about the idea of leveraging it for larger pieces of functionality as well. 


[1] http://www.mediawiki.org/wiki/Beta_Experiments",task_subcomment,"Hi MZMcBride, a desktop framework for beta testing features is already underway[1}, although it was originally envisioned for smaller experiments we can certainly think about the idea of leveraging it for larger pieces of functionality as well. 


[1] URL",FUTURE PLAN
54339,VisualEditor: Selection highlighting breaks if an inline alien wraps,"wrapped inline alien: incorrect highlighting in chromium

If an inline alien gets word wrapped, then selecting it leads to incorrect highlighting.

Reproducing: make a  ...  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}",task_description,"wrapped inline alien: incorrect highlighting in chromium

If an inline alien gets word wrapped, then selecting it leads to incorrect highlighting.

Reproducing: make a  ...  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}",BUG REPRODUCTION
253519,VisualEditor: Selection highlighting breaks if an inline alien wraps,*** Bug 67062 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 67062 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
253516,VisualEditor: Selection highlighting breaks if an inline alien wraps,"Change 139805 merged by jenkins-bot:
Shields are dead, long live getClientRects

https://gerrit.wikimedia.org/r/139805",task_subcomment,"Change 139805 merged by jenkins-bot:
Shields are dead, long live getClientRects

GERRIT_URL",ACTION ON ISSUE
253513,VisualEditor: Selection highlighting breaks if an inline alien wraps,"Change 139805 had a related patch set uploaded by Esanders:
Shields are dead, long live getClientRects

https://gerrit.wikimedia.org/r/139805",task_subcomment,"Change 139805 had a related patch set uploaded by Esanders:
Shields are dead, long live getClientRects

GERRIT_URL",SOLUTION USAGE
253509,VisualEditor: Selection highlighting breaks if an inline alien wraps,"Created attachment 13036
wrapped inline alien: incorrect highlighting in firefox

**Attached**: {F11840}",task_subcomment,"Created attachment 13036
wrapped inline alien: incorrect highlighting in firefox

**Attached**: {F11840}",BUG REPRODUCTION
253505,VisualEditor: Selection highlighting breaks if an inline alien wraps,"Created attachment 13035
wrapped inline alien: incorrect highlighting in firefox

//attachment wrapped-inline-alien-firefox.png ignored as obsolete//",task_subcomment,"Created attachment 13035
wrapped inline alien: incorrect highlighting in firefox

//attachment wrapped-inline-alien-firefox.png ignored as obsolete//",BUG REPRODUCTION
54326,VisualEditor: Toolbar overlaps top of page links,"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}",task_description,"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**:
URL
URL

**Attached**: {F11800}",BUG REPRODUCTION
252828,VisualEditor: Toolbar overlaps top of page links,"I guess https://bugzilla.wikimedia.org/show_bug.cgi?id=52433 is a duplicate then?
Thanks.",task_subcomment,"I guess URL is a duplicate then?
Thanks.",ACTION ON ISSUE
252824,VisualEditor: Toolbar overlaps top of page links,"This was fixed last week (but not deployed yet, sorry) - merging with the other report.

*** This bug has been marked as a duplicate of bug 52441 ***",task_subcomment,"This was fixed last week (but not deployed yet, sorry) - merging with the other report.

*** This bug has been marked as a duplicate of bug 52441 ***",ACTION ON ISSUE
252819,VisualEditor: Toolbar overlaps top of page links,"users Jay8g and Wouterstomp at en.wp have confirmed this happening in ""Monobook, FF 22, Windows 7"" and in Chrome (presumably on Windows) respectively.

Jay8g provided a screenshot at https://en.wikipedia.org/wiki/File:VE_error-top_bar_over_toolbar.jpg",task_subcomment,"users Jay8g and Wouterstomp at en.wp have confirmed this happening in ""Monobook, FF 22, Windows 7"" and in Chrome (presumably on Windows) respectively.

Jay8g provided a screenshot at URL",BUG REPRODUCTION
252812,VisualEditor: Toolbar overlaps top of page links,"**sandrobt.wiki** wrote:

It happen to me several tipe with MacOS 10.6 and Firexfox 22.0. 

I didn't need to do all those step to get this bug, it was enough to scroll down, modify something and then go back up. It doens't always happen, but when it doesn't, it is usually enough to repeati the above operation to get the overlapping.",task_subcomment,"**sandrobt.wiki** wrote:

It happen to me several tipe with MacOS 10.6 and Firexfox 22.0. 

I didn't need to do all those step to get this bug, it was enough to scroll down, modify something and then go back up. It doens't always happen, but when it doesn't, it is usually enough to repeati the above operation to get the overlapping.",BUG REPRODUCTION
252806,VisualEditor: Toolbar overlaps top of page links,"User CrypticC62 at en.wp has reproduced this in the following environments:


    Firefox 22 / Monobook / Windows Vista: Reproduced (followed steps, occurred in one attempt)
    Chrome 28 / Vector / Windows Vista: Found similar effect after step 3. See screenshot.


The screenshot referred to is [[File:VE Chrome Toolbar Overlap.png]]",task_subcomment,"User CrypticC62 at en.wp has reproduced this in the following environments:


    Firefox 22 / Monobook / Windows Vista: Reproduced (followed steps, occurred in one attempt)
    Chrome 28 / Vector / Windows Vista: Found similar effect after step 3. See screenshot.


The screenshot referred to is [[File:VE Chrome Toolbar Overlap.png]]",BUG REPRODUCTION
54276,VisualEditor: Localised tag description should link to content language documentation page,"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",task_description,"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] URL
[2] URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
249706,VisualEditor: Localised tag description should link to content language documentation page,Fixed; we'll deploy this later today.,task_subcomment,Fixed; we'll deploy this later today.,SOLUTION USAGE
249702,VisualEditor: Localised tag description should link to content language documentation page,"Change 76763 merged by jenkins-bot:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

https://gerrit.wikimedia.org/r/76763",task_subcomment,"Change 76763 merged by jenkins-bot:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

GERRIT_URL",ACTION ON ISSUE
249699,VisualEditor: Localised tag description should link to content language documentation page,"Change 76763 had a related patch set uploaded by Jforrester:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

https://gerrit.wikimedia.org/r/76763",task_subcomment,"Change 76763 had a related patch set uploaded by Jforrester:
Partial revert of gerrit 8ed6dfa5423 to avoid i18n mis-links

GERRIT_URL",TASK PROGRESS
249694,VisualEditor: Localised tag description should link to content language documentation page,This was caused by gerrit 75559 - will partially-revert.,task_subcomment,This was caused by gerrit 75559 - will partially-revert.,ACTION ON ISSUE
249689,VisualEditor: Localised tag description should link to content language documentation page,Right. It should probably be [[{{MediaWiki:visualeditor-descriptionpagelink}}|VisualEditor]].,task_subcomment,Right. It should probably be [[{{MediaWiki:visualeditor-descriptionpagelink}}|VisualEditor]].,SOLUTION USAGE
249683,VisualEditor: Localised tag description should link to content language documentation page,"[[mw:MediaWiki:Tag-visualeditor]] is using int: to fetch the visualeditor-descriptionpagelink, that should be done only for the content language. The link should be changed to {{MediaWiki:visualeditor-descriptionpagelink}}.

That is a problem in VisualEditor, moving component",task_subcomment,"[[mw:MediaWiki:Tag-visualeditor]] is using int: to fetch the visualeditor-descriptionpagelink, that should be done only for the content language. The link should be changed to {{MediaWiki:visualeditor-descriptionpagelink}}.

That is a problem in VisualEditor, moving component",BUG REPRODUCTION
54271,VisualEditor: Editing a pasted template alters copy buffer. Displayed result differs from saved result.,"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",task_description,"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 URL 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**:
URL",BUG REPRODUCTION
249423,VisualEditor: Editing a pasted template alters copy buffer. Displayed result differs from saved result.,"(In reply to comment #2)
> This appears to be fixed in master.

Confirmed - fixed in master, broken in wmf15. Marking as such.",task_subcomment,"(In reply to comment #2)
QUOTE

Confirmed - fixed in master, broken in wmf15. Marking as such.",SOLUTION USAGE
249416,VisualEditor: Editing a pasted template alters copy buffer. Displayed result differs from saved result.,This appears to be fixed in master.,task_subcomment,This appears to be fixed in master.,SOLUTION DISCUSSION
249410,VisualEditor: Editing a pasted template alters copy buffer. Displayed result differs from saved result.,"Mike Christie comments further:
What is saved is not always what you see on screen.

To reproduce in a sandbox:

Add a template such as {{chem}}; I used 14C, created by {{chem|14|C}}. Put some text on either side of it so you can copy/paste it with text, since templates won't copy/paste successfully by themselves.

Save that page, and edit again.


Now copy the template and paste it twice, so you have something like this:
-- 14C -- -- 14C -- -- 14C --

Now edit the first pasted one -- the middle one in the example above -- so that it changes a parameter:

-- 14C -- -- 12C -- -- 14C --

Paste again; the pasted version will be 12C, which is bug 52271.

a) I've seen two different behaviours for the next step. One is that you'll now see this:

-- 14C -- -- 12C -- -- 14C -- -- 12C --

but when you save the third one will be a 12 -- that is, it will have changed what you see on screen to be different in the saved file.

b) The other behaviour I've seen is that after the final paste, all four of the templates show ""12"", not ""14"".",task_subcomment,"Mike Christie comments further:
What is saved is not always what you see on screen.

To reproduce in a sandbox:

Add a template such as {{chem}}; I used 14C, created by {{chem|14|C}}. Put some text on either side of it so you can copy/paste it with text, since templates won't copy/paste successfully by themselves.

Save that page, and edit again.


Now copy the template and paste it twice, so you have something like this:
-- 14C -- -- 14C -- -- 14C --

Now edit the first pasted one -- the middle one in the example above -- so that it changes a parameter:

-- 14C -- -- 12C -- -- 14C --

Paste again; the pasted version will be 12C, which is bug 52271.

a) I've seen two different behaviours for the next step. One is that you'll now see this:

-- 14C -- -- 12C -- -- 14C -- -- 12C --

but when you save the third one will be a 12 -- that is, it will have changed what you see on screen to be different in the saved file.

b) The other behaviour I've seen is that after the final paste, all four of the templates show ""12"", not ""14"".",BUG REPRODUCTION
54256,"VisualEditor: Link widget in a slug fails with ""No class registered by that name: undefined""","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",task_description,"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**:
URL",BUG REPRODUCTION
248587,"VisualEditor: Link widget in a slug fails with ""No class registered by that name: undefined""",This seems to be fixed by https://gerrit.wikimedia.org/r/#/c/81437/,task_subcomment,This seems to be fixed by URL,SOLUTION USAGE
248582,"VisualEditor: Link widget in a slug fails with ""No class registered by that name: undefined""","It also copies the page name from the link widget to the document as apparent plain text, even though you exit out with double-ESC.",task_subcomment,"It also copies the page name from the link widget to the document as apparent plain text, even though you exit out with double-ESC.",BUG REPRODUCTION
248577,"VisualEditor: Link widget in a slug fails with ""No class registered by that name: undefined""","Created attachment 13014
Broken link widget after pressing Ctrl-K on empty page, then exiting

**Attached**: {F11679}",task_subcomment,"Created attachment 13014
Broken link widget after pressing Ctrl-K on empty page, then exiting

**Attached**: {F11679}",BUG REPRODUCTION
54238,VisualEditor: categories being duplicated,"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",task_description,"See URL and URL - no duplication (ahahaha) steps of which I'm aware, I'm afraid.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL",SOLUTION USAGE
247579,VisualEditor: categories being duplicated,Going out in a little while.,task_subcomment,Going out in a little while.,ACTION ON ISSUE
247574,VisualEditor: categories being duplicated,"Change 76665 merged by jenkins-bot:
Don't duplicate categories when unlisting

https://gerrit.wikimedia.org/r/76665",task_subcomment,"Change 76665 merged by jenkins-bot:
Don't duplicate categories when unlisting

GERRIT_URL",ACTION ON ISSUE
247569,VisualEditor: categories being duplicated,"Change 76665 had a related patch set uploaded by Catrope:
Don't duplicate categories when unlisting

https://gerrit.wikimedia.org/r/76665",task_subcomment,"Change 76665 had a related patch set uploaded by Catrope:
Don't duplicate categories when unlisting

GERRIT_URL",ACTION ON ISSUE
247565,VisualEditor: categories being duplicated,"Isolated test case:

1. Create a page with ""*Foo\n[[Category:Bar]]\n[[Category:Baz]]""
2. Edit the page in VE
3. Move the cursor to the end of the list item and press enter. This creates a new list item and puts the cursor in it
4. Click the list button (the one that's depressed) in the toolbar. This causes the list item to go away and makes the cursor jump out of the list.
5. Review changes. The diff will duplicate both of the categories at the beginning of the page, preceded by a newline.",task_subcomment,"Isolated test case:

1. Create a page with ""*Foo\n[[Category:Bar]]\n[[Category:Baz]]""
2. Edit the page in VE
3. Move the cursor to the end of the list item and press enter. This creates a new list item and puts the cursor in it
4. Click the list button (the one that's depressed) in the toolbar. This causes the list item to go away and makes the cursor jump out of the list.
5. Review changes. The diff will duplicate both of the categories at the beginning of the page, preceded by a newline.",BUG REPRODUCTION
247561,VisualEditor: categories being duplicated,http://youtu.be/1rmp5rTDPOM,task_subcomment,URL,ACTION ON ISSUE
54228,VisualEditor: VE will not save multiple consecutive references,"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",task_description,"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 (URL but when you save it only saves one (URL

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:
URL

I'm using Chrome, Windows 7.

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
247096,VisualEditor: VE will not save multiple consecutive references,"(In reply to comment #6)
> Users are reporting that VE is still not saving multiple references:

Unfortunately, this is ""again"", not ""still"", and is caused by bug 53434 in Parsoid, I think. :-( Marking this as ""fixed"" but highlighting on that one how urgent this is. Sorry for the disruption.",task_subcomment,"(In reply to comment #6)
QUOTE

Unfortunately, this is ""again"", not ""still"", and is caused by bug 53434 in Parsoid, I think. :-( Marking this as ""fixed"" but highlighting on that one how urgent this is. Sorry for the disruption.",ACTION ON ISSUE
247090,VisualEditor: VE will not save multiple consecutive references,"Users are reporting that VE is still not saving multiple references:

Reported today by The Devil's Advocate
if I add multiple citations to back a statement, the Visual Editor only saves the first citation I added. This happened once when I added three citations to back a claim and had to add each one individually over the course of three edits and again just now when I had to add a second citation after it didn't get saved. Multiple citations can be added if they are separate as I had added a citation for another statement in the same edit and it was saved.

Reported on the 22nd by Sue Gardner
Last night I created a new article with multiple references, and when I saved the page many of the references disappeared and some I think had jumped around. (I didn't save-as-I-went -- I wrote the whole thing and saved once, at the end.) I can't describe exactly what happened, but here's a diff: [1] the latest revision [2] is roughly what I was aiming to do, and the earlier revision [3] is what I actually achieved. (Ignore the missing reflist: I just hadn't gotten around to figuring out how to add it in VE yet, so I did it afterwards in wiki syntax.)

So, in my initial VE save, it looks like references #5, 6 & 7 disappeared as did #14 and 15. (Numbers taken from the latest revision.) This suggests to me there's a problem with VE saving multiple adjacent references -- when there are multiples adjacent, it seems to save only the first. I think also some references jumped around, but I'm not 100% sure about that.

[1] https://en.wikipedia.org/w/index.php?title=Mansplaining&diff=569638597&oldid=569526861
[2] https://en.wikipedia.org/w/index.php?title=Mansplaining&oldid=569638597
[3] https://en.wikipedia.org/w/index.php?title=Mansplaining&oldid=569526861",task_subcomment,"Users are reporting that VE is still not saving multiple references:

Reported today by The Devil's Advocate
if I add multiple citations to back a statement, the Visual Editor only saves the first citation I added. This happened once when I added three citations to back a claim and had to add each one individually over the course of three edits and again just now when I had to add a second citation after it didn't get saved. Multiple citations can be added if they are separate as I had added a citation for another statement in the same edit and it was saved.

Reported on the 22nd by Sue Gardner
Last night I created a new article with multiple references, and when I saved the page many of the references disappeared and some I think had jumped around. (I didn't save-as-I-went -- I wrote the whole thing and saved once, at the end.) I can't describe exactly what happened, but here's a diff: [1] the latest revision [2] is roughly what I was aiming to do, and the earlier revision [3] is what I actually achieved. (Ignore the missing reflist: I just hadn't gotten around to figuring out how to add it in VE yet, so I did it afterwards in wiki syntax.)

So, in my initial VE save, it looks like references #5, 6 & 7 disappeared as did #14 and 15. (Numbers taken from the latest revision.) This suggests to me there's a problem with VE saving multiple adjacent references -- when there are multiples adjacent, it seems to save only the first. I think also some references jumped around, but I'm not 100% sure about that.

[1] URL
[2] URL
[3] URL",BUG REPRODUCTION
247083,VisualEditor: VE will not save multiple consecutive references,*** Bug 52269 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52269 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
247078,VisualEditor: VE will not save multiple consecutive references,Fixed and will get deployed in a little while.,task_subcomment,Fixed and will get deployed in a little while.,SOLUTION USAGE
247072,VisualEditor: VE will not save multiple consecutive references,"Change 76836 merged by jenkins-bot:
Remove the DM 'about' attribute from references and reference lists

https://gerrit.wikimedia.org/r/76836",task_subcomment,"Change 76836 merged by jenkins-bot:
Remove the DM 'about' attribute from references and reference lists

GERRIT_URL",ACTION ON ISSUE
247064,VisualEditor: VE will not save multiple consecutive references,"Change 76836 had a related patch set uploaded by Catrope:
Remove the DM 'about' attribute from references and reference lists

https://gerrit.wikimedia.org/r/76836",task_subcomment,"Change 76836 had a related patch set uploaded by Catrope:
Remove the DM 'about' attribute from references and reference lists

GERRIT_URL",ACTION ON ISSUE
247055,VisualEditor: VE will not save multiple consecutive references,"This happens because we send Parsoid something like



which then gets about-grouped. We need to just drop the about attribute if we don't have it.

Ironically we've had breakage in the other direction before, where Parsoid output multiple adjacent images with about=""null"". Karma's a bitch :)",task_subcomment,"This happens because we send Parsoid something like



which then gets about-grouped. We need to just drop the about attribute if we don't have it.

Ironically we've had breakage in the other direction before, where Parsoid output multiple adjacent images with about=""null"". Karma's a bitch :)",MOTIVATION
54189,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"+++ 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",task_description,"+++ 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",BUG REPRODUCTION
244588,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"Change 119282 merged by jenkins-bot:
Prevent comparable annotations from being applied twice

https://gerrit.wikimedia.org/r/119282",task_subcomment,"Change 119282 merged by jenkins-bot:
Prevent comparable annotations from being applied twice

GERRIT_URL",ACTION ON ISSUE
244581,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"Change 119282 had a related patch set uploaded by Esanders:
Prevent comparable annotations from being applied twice

https://gerrit.wikimedia.org/r/119282",task_subcomment,"Change 119282 had a related patch set uploaded by Esanders:
Prevent comparable annotations from being applied twice

GERRIT_URL",ACTION ON ISSUE
244574,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"No it isn't: if you follow the STR, you will still see this bug on Firefox 25.",task_subcomment,"No it isn't: if you follow the STR, you will still see this bug on Firefox 25.",BUG REPRODUCTION
244567,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"This was the same bug as bug 50170, however; merging.

*** This bug has been marked as a duplicate of bug 50170 ***",task_subcomment,"This was the same bug as bug 50170, however; merging.

*** This bug has been marked as a duplicate of bug 50170 ***",ACTION ON ISSUE
244557,VisualEditor: Using bold button on partially bolded selection causes double-bolding,"(In reply to comment #0)
> this is narrower.

A narrower set of circumstances, not a narrower font!",task_subcomment,"(In reply to comment #0)
QUOTE

A narrower set of circumstances, not a narrower font!",SOLUTION DISCUSSION
54185,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"**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",task_description,"**Author:** CODE

**Description:**
To reproduce:

Goto URL

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**:
URL",BUG REPRODUCTION
244354,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"Pressing anything other than delete no longer does anything for me, which seems sensible.",task_subcomment,"Pressing anything other than delete no longer does anything for me, which seems sensible.",BUG REPRODUCTION
244347,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),Bumping; this is happening 100% of the time now.,task_subcomment,Bumping; this is happening 100% of the time now.,BUG REPRODUCTION
244340,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"**jonathan.haas** wrote:

Using the current Firefox 27 alpha (Aurora build), the problem seems to be much worse, as the pawn appears reliably in step 2 just after pressing ""a"". Maybe it's a different issue, but maybe it helps debugging this one.

TBH, this pawn stuff seems to be very weird and unstable to me. Why can they appear in the first place?",task_subcomment,"**jonathan.haas** wrote:

Using the current Firefox 27 alpha (Aurora build), the problem seems to be much worse, as the pawn appears reliably in step 2 just after pressing ""a"". Maybe it's a different issue, but maybe it helps debugging this one.

TBH, this pawn stuff seems to be very weird and unstable to me. Why can they appear in the first place?",BUG REPRODUCTION
244333,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"I can occasionally reproduce this in Chrome and Firefox, but not reliably (roughly 1 in 10 replacements). Race condition on the change stack or something?",task_subcomment,"I can occasionally reproduce this in Chrome and Firefox, but not reliably (roughly 1 in 10 replacements). Race condition on the change stack or something?",BUG REPRODUCTION
244325,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"**p.selitskas** wrote:

I could reproduce this with cyrillic letters in be-x-old.wikipedia.org, at least a few weeks ago.",task_subcomment,"**p.selitskas** wrote:

I could reproduce this with cyrillic letters in be-x-old.wikipedia.org, at least a few weeks ago.",BUG REPRODUCTION
244318,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),I can't reproduce after about 20 tries in Firefox 23/Linux/Monobook,task_subcomment,I can't reproduce after about 20 tries in Firefox 23/Linux/Monobook,BUG REPRODUCTION
244313,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"**jonathan_haas** wrote:

Screenshot

Also managed to reproduce in Chrome 28.

No error in javascript console in both browsers.

**Attached**: {F11523}",task_subcomment,"**jonathan_haas** wrote:

Screenshot

Also managed to reproduce in Chrome 28.

No error in javascript console in both browsers.

**Attached**: {F11523}",MOTIVATION
244307,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),"**jonathan_haas** wrote:

I still can (FF23). Just managed on first try.",task_subcomment,"**jonathan_haas** wrote:

I still can (FF23). Just managed on first try.",TASK PROGRESS
244301,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),Can't reproduce in Chrome or FF,task_subcomment,Can't reproduce in Chrome or FF,BUG REPRODUCTION
244295,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),This is possibly bug 51532,task_subcomment,This is possibly bug 51532,BUG REPRODUCTION
244291,VisualEditor: Replacing a selected template with a keyboard press creates a pawn (♙),Reproduced; I havent looked to see if this scenario has been reported already.,task_subcomment,Reproduced; I havent looked to see if this scenario has been reported already.,BUG REPRODUCTION
54181,"Be able to add or remove tables, table rows and table columns","**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",task_description,"**Author:** CODE

**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**:
URL",BUG REPRODUCTION
244077,"Be able to add or remove tables, table rows and table columns",post-deploy testing in test2 - VisualEditor has added functiona lity to insert/remove tables and modify tables - insert columns and rows  in tables.,task_subcomment,post-deploy testing in test2 - VisualEditor has added functiona lity to insert/remove tables and modify tables - insert columns and rows  in tables.,TASK PROGRESS
244074,"Be able to add or remove tables, table rows and table columns",Done in gerrit 159310 and related stack.,task_subcomment,Done in gerrit 159310 and related stack.,SOLUTION USAGE
244068,"Be able to add or remove tables, table rows and table columns","Swedish Wikipedian Sebbes333 [1] reports here [2] that he ""would like to insert a new column in a 2D table, [however] do not think it will go into beta editor yet."" 

[1]
https://sv.wikipedia.org/wiki/Anv%C3%A4ndare:Sebbes333

[2]
https://sv.wikipedia.org/wiki/Wikipedia:VisualEditor/%C3%85terkoppling#Infoga_ny_kolumn_i_en_2D_tabell_i_beta_redigeraren.",task_subcomment,"Swedish Wikipedian Sebbes333 [1] reports here [2] that he ""would like to insert a new column in a 2D table, [however] do not think it will go into beta editor yet."" 

[1]
URL

[2]
URL",FUTURE PLAN
244063,"Be able to add or remove tables, table rows and table columns",*** Bug 53325 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53325 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
244058,"Be able to add or remove tables, table rows and table columns","Ok, will move it elsewhere. Thanks.",task_subcomment,"Ok, will move it elsewhere. Thanks.",ISSUE CONTENT MANAGEMENT
244054,"Be able to add or remove tables, table rows and table columns","**jonathan_haas** wrote:

(In reply to comment #2)
> < of a
> table with an empty cell, VE seemed to move the two pipes inside the cell on
> the left, and the empty cell didn't show. -- t numbermaniac c 03:02, 6 August
> 2013 (UTC)>> (first line of the Redirect table in
> http://en.wikipedia.org/wiki/User:Numbermaniac?veaction=edit ).

Confirmed, but I think this deserves another, separate bug report.",task_subcomment,"**jonathan_haas** wrote:

(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Confirmed, but I think this deserves another, separate bug report.",SOLUTION DISCUSSION
244051,"Be able to add or remove tables, table rows and table columns","<> (first line of the Redirect table in http://en.wikipedia.org/wiki/User:Numbermaniac?veaction=edit ).",task_subcomment,"<> (first line of the Redirect table in URL ).",BUG REPRODUCTION
244047,"Be able to add or remove tables, table rows and table columns",I couldnt find another bug for creating tables.,task_subcomment,I couldnt find another bug for creating tables.,BUG REPRODUCTION
54175,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","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//",task_description,"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**:
URL

//attachment VE_de_Firefox_save_dialog .png ignored as obsolete//",BUG REPRODUCTION
243771,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings",The line-height is too large and the second line is offset to left.,task_subcomment,The line-height is too large and the second line is offset to left.,BUG REPRODUCTION
243764,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings",Reset as FIXED. The screenshot you attach looks normal - could you annotate the parts you think aren't correct? Probably as a new bug…,task_subcomment,Reset as FIXED. The screenshot you attach looks normal - could you annotate the parts you think aren't correct? Probably as a new bug…,ACTION ON ISSUE
243757,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","Created attachment 13820
Screenshot, 2013-11-17 (in Polish)

This appears to still not fixed :( I'm adding an up-to-date screenshot.

**Attached**: {F11479}",task_subcomment,"Created attachment 13820
Screenshot, 2013-11-17 (in Polish)

This appears to still not fixed :( I'm adding an up-to-date screenshot.

**Attached**: {F11479}",BUG REPRODUCTION
243750,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.",task_subcomment,"The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.",ACTION ON ISSUE
243742,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876",task_subcomment,"Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

GERRIT_URL",SOLUTION USAGE
243735,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings",*** Bug 54802 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54802 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
243729,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876",task_subcomment,"Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

GERRIT_URL",SOLUTION USAGE
243722,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","Created attachment 13242
pl.wp screenshot

It breaks particularly badly on wikis with FlaggedRevs.

//attachment 2013-09-04 22_07_50-Edytujesz Rafał Kosik - Wikipedia - Opera.png ignored as obsolete//",task_subcomment,"Created attachment 13242
pl.wp screenshot

It breaks particularly badly on wikis with FlaggedRevs.

//attachment 2013-09-04 22_07_50-Edytujesz Rafał Kosik - Wikipedia - Opera.png ignored as obsolete//",BUG REPRODUCTION
243716,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings",*** Bug 52176 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52176 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
243710,"VisualEditor: Save dialog's checkboxes layout terribly if you have more than 2 items, or long i18n strings","Created attachment 12997
Windows 7 screenshot

Font is obviously a contributing factor here; on Windows the layout problem almost disappears.

//attachment VE_de_save_dialog_checkboxes_Firefox_on_Windows.png ignored as obsolete//",task_subcomment,"Created attachment 12997
Windows 7 screenshot

Font is obviously a contributing factor here; on Windows the layout problem almost disappears.

//attachment VE_de_save_dialog_checkboxes_Firefox_on_Windows.png ignored as obsolete//",BUG REPRODUCTION
54171,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,"**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",task_description,"**Author:** CODE

**Description:**
To reproduce:

1. Goto URL
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",BUG REPRODUCTION
243512,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,Confirmed now fixed.,task_subcomment,Confirmed now fixed.,TASK PROGRESS
243505,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,WFM in Firefox,task_subcomment,WFM in Firefox,WORKAROUND
243501,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,"(In reply to Jonathan Haas from comment #4)
> The underlying bug doesn't seem to be fixed.
> 
> To reproduce (Linux, Firefox):
> 
> 1. Copy the Text ""Foundation"" (without quotation marks) to the clipboard
> 2. Open: https://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
> 3. Select all (Ctrl+A)
> 4. Paste Clipboard (Ctrl+V)
> 5. Type ""foobar""
> 
> Expected result:
> 
> Page contains ""Foundationfoobar""
> 
> Actual result:
> 
> Page contains:
> 
> obar|
> 
> oo
> 
> fo
> Foundationf


Interesting. This worked for me when I tested it, but doesn't now; perhaps it's content-driven (as well as being a symptom of how broken bits of Firefox are).",task_subcomment,"(In reply to Jonathan Haas from comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE


Interesting. This worked for me when I tested it, but doesn't now; perhaps it's content-driven (as well as being a symptom of how broken bits of Firefox are).",SOLUTION DISCUSSION
243495,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,"**jonathan_haas** wrote:

The underlying bug doesn't seem to be fixed.

To reproduce (Linux, Firefox):

1. Copy the Text ""Foundation"" (without quotation marks) to the clipboard
2. Open: https://de.wikipedia.org/wiki/The_Binding_of_Isaac?veaction=edit
3. Select all (Ctrl+A)
4. Paste Clipboard (Ctrl+V)
5. Type ""foobar""

Expected result:

Page contains ""Foundationfoobar""

Actual result:

Page contains:

obar|

oo

fo
Foundationf",task_subcomment,"**jonathan_haas** wrote:

The underlying bug doesn't seem to be fixed.

To reproduce (Linux, Firefox):

1. Copy the Text ""Foundation"" (without quotation marks) to the clipboard
2. Open: URL
3. Select all (Ctrl+A)
4. Paste Clipboard (Ctrl+V)
5. Type ""foobar""

Expected result:

Page contains ""Foundationfoobar""

Actual result:

Page contains:

obar|

oo

fo
Foundationf",BUG REPRODUCTION
243488,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,Was fixed by something Ed did a while ago.,task_subcomment,Was fixed by something Ed did a while ago.,SOLUTION USAGE
243481,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,"**jonathan_haas** wrote:

Note that the above result was created using Firefox 23.

Chrome 28 produces the following (equally wrong) result:

fbar|ofo
o
foo",task_subcomment,"**jonathan_haas** wrote:

Note that the above result was created using Firefox 23.

Chrome 28 produces the following (equally wrong) result:

fbar|ofo
o
foo",BUG REPRODUCTION
243475,VisualEditor: Select-all and typing makes document significantly out-of-sync in Firefox,Reproduced.,task_subcomment,Reproduced.,BUG REPRODUCTION
54160,VisualEditor: [Regression] Reference list not being updated during editing session,"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",task_description,"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",BUG REPRODUCTION
242786,VisualEditor: [Regression] Reference list not being updated during editing session,"@Cainamarques, please see https://bugzilla.wikimedia.org/show_bug.cgi?id=57209 and comment there if you really manage to properly see and choose from the list of reusable references. Thanks.",task_subcomment,"SCREEN_NAME, please see URL and comment there if you really manage to properly see and choose from the list of reusable references. Thanks.",ACTION ON ISSUE
242781,VisualEditor: [Regression] Reference list not being updated during editing session,"This bug seems to be fixed, I can perfectly edit and reuse references using Firefox 25.0",task_subcomment,"This bug seems to be fixed, I can perfectly edit and reuse references using Firefox 25.0",BUG REPRODUCTION
242778,VisualEditor: [Regression] Reference list not being updated during editing session,(Wondering if this is related to https://bugzilla.wikimedia.org/show_bug.cgi?id=51689.),task_subcomment,(Wondering if this is related to URL,BUG REPRODUCTION
242776,VisualEditor: [Regression] Reference list not being updated during editing session,"Likewise, the reference list is not updated if I add a new reference to the page, thus being unable to reuse it in the current edit.",task_subcomment,"Likewise, the reference list is not updated if I add a new reference to the page, thus being unable to reuse it in the current edit.",BUG REPRODUCTION
242774,VisualEditor: [Regression] Reference list not being updated during editing session,"Confirmed.  Use existing reference shows original references, before they were modified.",task_subcomment,"Confirmed.  Use existing reference shows original references, before they were modified.",BUG REPRODUCTION
54159,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","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",task_description,"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",BUG REPRODUCTION
242730,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is",*** Bug 52594 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52594 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
242728,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","Should now be fixed; we will deploy this earlier than scheduled, later today.",task_subcomment,"Should now be fixed; we will deploy this earlier than scheduled, later today.",SOLUTION USAGE
242726,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","Change 80056 merged by jenkins-bot:
Preserve selection when inserting references

https://gerrit.wikimedia.org/r/80056",task_subcomment,"Change 80056 merged by jenkins-bot:
Preserve selection when inserting references

GERRIT_URL",ACTION ON ISSUE
242723,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","Change 80056 had a related patch set uploaded by Esanders:
Preserve selection when inserting references

https://gerrit.wikimedia.org/r/80056",task_subcomment,"Change 80056 had a related patch set uploaded by Esanders:
Preserve selection when inserting references

GERRIT_URL",ACTION ON ISSUE
242717,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","AFAICT this only happens in the first paragraph (and only in Firefox).

This is throwing an error in Rangy:

  TypeError: sel.nativeSelection is null
  sel._ranges.length = sel.rangeCount = sel.nativeSelection.rangeCount;

… but for some reason I can't get Firebug to give me a trace.",task_subcomment,"AFAICT this only happens in the first paragraph (and only in Firefox).

This is throwing an error in Rangy:

  TypeError: sel.nativeSelection is null
  sel._ranges.length = sel.rangeCount = sel.nativeSelection.rangeCount;

… but for some reason I can't get Firebug to give me a trace.",BUG REPRODUCTION
242711,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","At en.wp WhatamIdoing reports:
I was just trying to add the ref to the other sentences. It misplaced two copies at the start of the paragraph when I wanted one at the end of the first line of the first paragraph (perhaps I clicked too high on the top line of the edit window?). After I removed those, I couldn't add any more. Clicking the ref button did nothing."" He gives the following URL:
https://en.wikipedia.org/w/index.php?title=Swing_%28seat%29&diff=568557479&oldid=568556853",task_subcomment,"At en.wp WhatamIdoing reports:
I was just trying to add the ref to the other sentences. It misplaced two copies at the start of the paragraph when I wanted one at the end of the first line of the first paragraph (perhaps I clicked too high on the top line of the edit window?). After I removed those, I couldn't add any more. Clicking the ref button did nothing."" He gives the following URL:
URL",BUG REPRODUCTION
242707,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","I have done similar manipulations in other articles at some moments, and it seems it sometimes works and sometimes doesn't. There are many things that are strange concerning how the existing references system works.

Regardless, I set up a sandbox page on my user space, added a reference and then tried to re-use that reference using the VisualEditor. The reference was added at the start of the paragraph. I've done some more experimenting, and I've written steps to reproduce the bug; the first block reproduces the bug and the following blocks are other experimentations that give more strange results.

1. Go to [[User:Rastus Vernon/VisualEditor Sandbox]].
2. Edit the page with the VisualEditor.
3. Click somewhere in the first paragraph, not at the start.
4. Click on the reference button and re-use the reference (there is only one).
5. Note how the reference was inserted at the start of the paragraph instead of being inserted where your cursor was.

6. Click in another paragraph, not at the start.
7. Insert the same reference again.
8. Note how the reference was inserted at the right position.

9. Perform steps 7 and 8 again.
10. Note how it was again inserted at the right position, although the reference is already in that paragraph.

11. Try inserting it again in the first paragraph.
12. Note how it still inserts it at the start of the paragraph instead of inserting it in the right location.

13. Be confused because you don't understand anything about this inconsistent behavior.",task_subcomment,"I have done similar manipulations in other articles at some moments, and it seems it sometimes works and sometimes doesn't. There are many things that are strange concerning how the existing references system works.

Regardless, I set up a sandbox page on my user space, added a reference and then tried to re-use that reference using the VisualEditor. The reference was added at the start of the paragraph. I've done some more experimenting, and I've written steps to reproduce the bug; the first block reproduces the bug and the following blocks are other experimentations that give more strange results.

1. Go to [[User:Rastus Vernon/VisualEditor Sandbox]].
2. Edit the page with the VisualEditor.
3. Click somewhere in the first paragraph, not at the start.
4. Click on the reference button and re-use the reference (there is only one).
5. Note how the reference was inserted at the start of the paragraph instead of being inserted where your cursor was.

6. Click in another paragraph, not at the start.
7. Insert the same reference again.
8. Note how the reference was inserted at the right position.

9. Perform steps 7 and 8 again.
10. Note how it was again inserted at the right position, although the reference is already in that paragraph.

11. Try inserting it again in the first paragraph.
12. Note how it still inserts it at the start of the paragraph instead of inserting it in the right location.

13. Be confused because you don't understand anything about this inconsistent behavior.",BUG REPRODUCTION
242702,"VisualEditor: Inserting an existing reference in the first paragraph in Firefox puts it at the start of the paragraph, not where the cursor is","I did only a quick test, and could not reproduce this bug.  Could you give more detailed instructions?",task_subcomment,"I did only a quick test, and could not reproduce this bug.  Could you give more detailed instructions?",BUG REPRODUCTION
54127,VisualEditor: Editing a link spanning a comment splits the link,"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)
[http://www.koreatimes.co.kr/ (The Korea Times)][http://www.koreatimes.co.kr/www/news/nation/nation_view.asp?newsIdx=5635&categoryCode=115 ]

--------------------------
**Version**: unspecified
**Severity**: major",task_description,"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 ""URL (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)
[URL (The Korea Times)][URL ]

--------------------------
**Version**: unspecified
**Severity**: major",BUG REPRODUCTION
241067,VisualEditor: Editing a link spanning a comment splits the link,"This is now fixed because comments are editable (finally), but there's a wider, lower-priority issue for non-comments, for which I have created bug 68779 to track.",task_subcomment,"This is now fixed because comments are editable (finally), but there's a wider, lower-priority issue for non-comments, for which I have created bug 68779 to track.",SOLUTION USAGE
241062,VisualEditor: Editing a link spanning a comment splits the link,"(In reply to Gerrit Notification Bot from comment #3)
> Change 141063 merged by jenkins-bot:
> Also annotate metadata in TransactionProcessor
> 
> https://gerrit.wikimedia.org/r/141063

Helpfully, this doesn't actually fix the bug (just a number of related bugs where the comment isn't on the edge of the link). Assigned.",task_subcomment,"(In reply to Gerrit Notification Bot from comment #3)
QUOTE
QUOTE
QUOTE
QUOTE

Helpfully, this doesn't actually fix the bug (just a number of related bugs where the comment isn't on the edge of the link). Assigned.",ACTION ON ISSUE
241055,VisualEditor: Editing a link spanning a comment splits the link,"Change 141063 merged by jenkins-bot:
Also annotate metadata in TransactionProcessor

https://gerrit.wikimedia.org/r/141063",task_subcomment,"Change 141063 merged by jenkins-bot:
Also annotate metadata in TransactionProcessor

GERRIT_URL",SOLUTION DISCUSSION
241049,VisualEditor: Editing a link spanning a comment splits the link,"Change 141063 had a related patch set uploaded by Catrope:
Also annotate metadata in TransactionProcessor

https://gerrit.wikimedia.org/r/141063",task_subcomment,"Change 141063 had a related patch set uploaded by Catrope:
Also annotate metadata in TransactionProcessor

GERRIT_URL",SOLUTION DISCUSSION
241044,VisualEditor: Editing a link spanning a comment splits the link,"This is a more general problem. We never unannotate comments or any other metadata. For instance:

* If you have [[Foo|BarQuux]] and change the link target, you'll split the link: [[Foo2|Bar]][[Foo|]][[Foo2|Quux]] (that's also what happened here)
* If you have FooBaz, it renders as ""FooBar"". If you then make that italic, you'll get ''Foo''''Baz''

The root of the problem is that ve.dm.TransactionProcessor#applyAnnotations doesn't annotate/unannotate metadata. Tomorrow I'll see if I can write a failing test case and fix applyAnnotations()",task_subcomment,"This is a more general problem. We never unannotate comments or any other metadata. For instance:

* If you have [[Foo|BarQuux]] and change the link target, you'll split the link: [[Foo2|Bar]][[Foo|]][[Foo2|Quux]] (that's also what happened here)
* If you have FooBaz, it renders as ""FooBar"". If you then make that italic, you'll get ''Foo''''Baz''

The root of the problem is that ve.dm.TransactionProcessor#applyAnnotations doesn't annotate/unannotate metadata. Tomorrow I'll see if I can write a failing test case and fix applyAnnotations()",INVESTIGATION AND EXPLORATION
54120,browsertests: triggers for ULS,"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",task_description,"This makes sense for ULS because they have a reasonable number of merges in a day, see URL 

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**:
URL
URL
URL",SOLUTION DISCUSSION
240724,browsertests: triggers for ULS,The job got fixed yesterday and browser tests are passing right now. It is not blocking changes yet though.,task_subcomment,The job got fixed yesterday and browser tests are passing right now. It is not blocking changes yet though.,TASK PROGRESS
240715,browsertests: triggers for ULS,"The trigger has been added in Zuul with https://gerrit.wikimedia.org/r/97741

The job will success whenever ULS change https://gerrit.wikimedia.org/r/#/c/97487/ is merged in.",task_subcomment,"The trigger has been added in Zuul with GERRIT_URL

The job will success whenever ULS change URL is merged in.",TASK PROGRESS
240708,browsertests: triggers for ULS,"Change 97741 merged by jenkins-bot:
ULS browsertests on check pipeline

https://gerrit.wikimedia.org/r/97741",task_subcomment,"Change 97741 merged by jenkins-bot:
ULS browsertests on check pipeline

GERRIT_URL",TASK PROGRESS
240702,browsertests: triggers for ULS,"Change 97741 had a related patch set uploaded by Hashar:
ULS browsertests on check pipeline

https://gerrit.wikimedia.org/r/97741",task_subcomment,"Change 97741 had a related patch set uploaded by Hashar:
ULS browsertests on check pipeline

GERRIT_URL",TASK PROGRESS
240695,browsertests: triggers for ULS,"The browser tests manage to pass with above change:

https://integration.wikimedia.org/ci/job/mwext-browsertests-UniversalLanguageSelector-phantomjs/27/consoleFull

With a nice HTML report:
https://integration.wikimedia.org/ci/job/mwext-browsertests-UniversalLanguageSelector-phantomjs/27/artifact/report.html

Whenever the change in comment #5 is merged in, I will validate with i18n team how to get it triggered by Zuul.",task_subcomment,"The browser tests manage to pass with above change:

URL

With a nice HTML report:
URL

Whenever the change in comment #5 is merged in, I will validate with i18n team how to get it triggered by Zuul.",SOLUTION USAGE
240687,browsertests: triggers for ULS,"Following a pair session with Željko, the tests can be flagged with a tag which we can then exclude when running tests. For ULS, I have introduced the tag @specific-settings which let us skip any tests that are not going to pass on a fresh wiki installation: https://gerrit.wikimedia.org/r/#/c/97487/",task_subcomment,"Following a pair session with Željko, the tests can be flagged with a tag which we can then exclude when running tests. For ULS, I have introduced the tagSCREEN_NAME-settings which let us skip any tests that are not going to pass on a fresh wiki installation: URL",TASK PROGRESS
240680,browsertests: triggers for ULS,Moving this under Continuous Integration radar.,task_subcomment,Moving this under Continuous Integration radar.,ACTION ON ISSUE
240672,browsertests: triggers for ULS,Have added bug 53691 for the same for the VisualEditor repo.,task_subcomment,Have added bug 53691 for the same for the VisualEditor repo.,BUG REPRODUCTION
240665,browsertests: triggers for ULS,What about running the tests on patch submission?,task_subcomment,What about running the tests on patch submission?,TASK PROGRESS
240659,browsertests: triggers for ULS,"Is this still something we want to do? ULS tests are now in ULS repo, so this should be doable. The only problem is that ULS tests are not stable enough:

https://wmf.ci.cloudbees.com/view/r-uls/",task_subcomment,"Is this still something we want to do? ULS tests are now in ULS repo, so this should be doable. The only problem is that ULS tests are not stable enough:

URL",SOLUTION DISCUSSION
54113,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),"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",task_description,"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**:
URL
URL",BUG REPRODUCTION
240258,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),Now merged into master; will be deployed in the next push.,task_subcomment,Now merged into master; will be deployed in the next push.,TASK PROGRESS
240252,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),"Change 79049 merged by jenkins-bot:
Check for past/future state in undo/redo before setting breakpoint

https://gerrit.wikimedia.org/r/79049",task_subcomment,"Change 79049 merged by jenkins-bot:
Check for past/future state in undo/redo before setting breakpoint

GERRIT_URL",SOLUTION USAGE
240247,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),"Change 79049 had a related patch set uploaded by Esanders:
Check for past/future state in undo/redo before setting breakpoint

https://gerrit.wikimedia.org/r/79049",task_subcomment,"Change 79049 had a related patch set uploaded by Esanders:
Check for past/future state in undo/redo before setting breakpoint

GERRIT_URL",TASK PROGRESS
240245,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),It's obviusly inviting you to play chess :),task_subcomment,It's obviusly inviting you to play chess :),SOCIAL CONVERSATION
240242,VisualEditor: Undo keyboard shortcuts clear undo / redo history if pressed too often (And other fun),I've reproduced a few of these permutations.,task_subcomment,I've reproduced a few of these permutations.,BUG REPRODUCTION
54112,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),"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}",task_description,"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}",BUG REPRODUCTION
240216,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),This appears to now be fixed - marking as WORKSFORME.,task_subcomment,This appears to now be fixed - marking as WORKSFORME.,WORKAROUNDS
240215,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),I can't reproduce this.,task_subcomment,I can't reproduce this.,BUG REPRODUCTION
240214,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),Thought we had fixed insertion into slugs in bug 44084 - has this re-surfaced?,task_subcomment,Thought we had fixed insertion into slugs in bug 44084 - has this re-surfaced?,BUG REPRODUCTION
240212,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),"Having tested a few more scenario's it would seem that editing near templates in general causes console errors, though none of these seem to cause any lasting issues.

- Selecting the line mentioned in step 2 and pressing enter will return the console error ""TypeError: outermostNode is null""
- Typing a text under the bottom template of the page and then pressing backpace till the text and that template are gone will cause an error if that edit is undone afterwards:
-- ""Error: Range error: Range is no longer valid after DOM mutation ""
-- ""Error: Offset could not be translated to a DOM element and offset: 1405""

As mentioned before, neither of these errors seem to impact anything in the editor or the edit itself.",task_subcomment,"Having tested a few more scenario's it would seem that editing near templates in general causes console errors, though none of these seem to cause any lasting issues.

- Selecting the line mentioned in step 2 and pressing enter will return the console error ""TypeError: outermostNode is null""
- Typing a text under the bottom template of the page and then pressing backpace till the text and that template are gone will cause an error if that edit is undone afterwards:
-- ""Error: Range error: Range is no longer valid after DOM mutation ""
-- ""Error: Offset could not be translated to a DOM element and offset: 1405""

As mentioned before, neither of these errors seem to impact anything in the editor or the edit itself.",BUG REPRODUCTION
240209,VisualEditor: Inserting template into slug throws JS error (causing dialogs to break),"Relevant error: ""Error: Offset could not be translated to a DOM element and offset: 1407""

The inability to open other dialogs is because the error causes the first dialog to never close, and so opening other dialogs fails because VE thinks you've already got a dialog open.

Is this due to adding a transclusion in a slug, perhaps?",task_subcomment,"Relevant error: ""Error: Offset could not be translated to a DOM element and offset: 1407""

The inability to open other dialogs is because the error causes the first dialog to never close, and so opening other dialogs fails because VE thinks you've already got a dialog open.

Is this due to adding a transclusion in a slug, perhaps?",BUG REPRODUCTION
54102,VisualEditor: Write newFromDocumentReplace so editing document slices is simple,"
--------------------------
**Version**: unspecified
**Severity**: major",task_description,"
--------------------------
**Version**: unspecified
**Severity**: major",BUG REPRODUCTION
239685,VisualEditor: Write newFromDocumentReplace so editing document slices is simple,"Change 82790 merged by jenkins-bot:
Introduce newFromDocumentReplace() transaction builder

https://gerrit.wikimedia.org/r/82790",task_subcomment,"Change 82790 merged by jenkins-bot:
Introduce newFromDocumentReplace() transaction builder

GERRIT_URL",ACTION ON ISSUE
239683,VisualEditor: Write newFromDocumentReplace so editing document slices is simple,"Change 82790 had a related patch set uploaded by Jforrester:
Introduce newFromDocumentReplace() transaction builder

https://gerrit.wikimedia.org/r/82790",task_subcomment,"Change 82790 had a related patch set uploaded by Jforrester:
Introduce newFromDocumentReplace() transaction builder

GERRIT_URL",SOLUTION USAGE
239682,VisualEditor: Write newFromDocumentReplace so editing document slices is simple,"Change 71661 abandoned by Catrope:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

Reason:
Superseded by https://gerrit.wikimedia.org/r/82790

https://gerrit.wikimedia.org/r/71661",task_subcomment,"Change 71661 abandoned by Catrope:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

Reason:
Superseded by GERRIT_URL

GERRIT_URL",ACTION ON ISSUE
239678,VisualEditor: Write newFromDocumentReplace so editing document slices is simple,"Change 71661 had a related patch set uploaded by Jforrester:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

https://gerrit.wikimedia.org/r/71661",task_subcomment,"Change 71661 had a related patch set uploaded by Jforrester:
[WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2

GERRIT_URL",ACTION ON ISSUE
54093,"VisualEditor: Make the ""wikitext"" link of the popup open in a new window","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",task_description,"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**:
URL
URL",INVESTIGATION AND EXPLORATION
239240,"VisualEditor: Make the ""wikitext"" link of the popup open in a new window",This is now done and we'll get it deployed soon.,task_subcomment,This is now done and we'll get it deployed soon.,TASK PROGRESS
239235,"VisualEditor: Make the ""wikitext"" link of the popup open in a new window","Change 76701 merged by jenkins-bot:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701",task_subcomment,"Change 76701 merged by jenkins-bot:
Set links in wikitext warning to load in new window

GERRIT_URL",TASK PROGRESS
239229,"VisualEditor: Make the ""wikitext"" link of the popup open in a new window","Change 76701 had a related patch set uploaded by Helder.wiki:
Set links in wikitext warning to load in new window

https://gerrit.wikimedia.org/r/76701",task_subcomment,"Change 76701 had a related patch set uploaded by Helder.wiki:
Set links in wikitext warning to load in new window

GERRIT_URL",SOLUTION USAGE
54077,APIEditBeforeSave isn't replacing sections like the documentation claims,"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}",task_description,"Reported: URL
and
URL

**See Also**:
* {T54049}
* {T54062}",ACTION ON ISSUE
641845,APIEditBeforeSave isn't replacing sections like the documentation claims,"I think this really was a problem with AbuseFilter and not the hook; the hook documentation was unclear. My fix for T73947 fixes this too, so I proposed that the patch be reverted at https://gerrit.wikimedia.org/r/282101.",task_subcomment,"I think this really was a problem with AbuseFilter and not the hook; the hook documentation was unclear. My fix for T73947 fixes this too, so I proposed that the patch be reverted at GERRIT_URL.",BUG REPRODUCTION
238424,APIEditBeforeSave isn't replacing sections like the documentation claims,*** Bug 52895 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52895 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
238419,APIEditBeforeSave isn't replacing sections like the documentation claims,*** Bug 52062 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52062 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
238414,APIEditBeforeSave isn't replacing sections like the documentation claims,"Change 76082 merged by jenkins-bot:
Make APIEditBeforeSave give the whole revision

https://gerrit.wikimedia.org/r/76082",task_subcomment,"Change 76082 merged by jenkins-bot:
Make APIEditBeforeSave give the whole revision

GERRIT_URL",ACTION ON ISSUE
238408,APIEditBeforeSave isn't replacing sections like the documentation claims,"See also:
* [[Wikipedia talk:Edit filter#Abusefilter bug on mobile version]]",task_subcomment,"See also:
* [[Wikipedia talk:Edit filter#Abusefilter bug on mobile version]]",WORKAROUNDS
238403,APIEditBeforeSave isn't replacing sections like the documentation claims,"Change 76082 had a related patch set uploaded by Hoo man:
Make APIEditBeforeSave give the whole revision

https://gerrit.wikimedia.org/r/76082",task_subcomment,"Change 76082 had a related patch set uploaded by Hoo man:
Make APIEditBeforeSave give the whole revision

GERRIT_URL",ACTION ON ISSUE
238396,APIEditBeforeSave isn't replacing sections like the documentation claims,"After some investigation it turns out, that this is an issue with the edit API. I'm just preparing a fix, but takes some time as both the API and EditPage itself are rather messy.",task_subcomment,"After some investigation it turns out, that this is an issue with the edit API. I'm just preparing a fix, but takes some time as both the API and EditPage itself are rather messy.",SOLUTION DISCUSSION
238389,APIEditBeforeSave isn't replacing sections like the documentation claims,Hoo suspects that this is a problem with VisualEditor. Copying a few folks accordingly.,task_subcomment,Hoo suspects that this is a problem with VisualEditor. Copying a few folks accordingly.,ACTION ON ISSUE
238385,APIEditBeforeSave isn't replacing sections like the documentation claims,"Marius, can you take a look at these? Chris is on vacation right now.",task_subcomment,"Marius, can you take a look at these? Chris is on vacation right now.",ACTION ON ISSUE
238380,APIEditBeforeSave isn't replacing sections like the documentation claims,"The edits in question:
https://en.wikipedia.org/w/index.php?title=Christoph_Waltz&diff=565783472&oldid=565445126

and

https://en.wikipedia.org/w/index.php?title=Stone_Gossard&diff=565724723&oldid=563438457",task_subcomment,"The edits in question:
URL

and

URL",SOLUTION DISCUSSION
54029,"VisualEditor: Template parameters with ""autofill"" TemplateData status should be autofilled","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",task_description,"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",SOLUTION DISCUSSION
234969,"VisualEditor: Template parameters with ""autofill"" TemplateData status should be autofilled","Change 146396 merged by jenkins-bot:
Add 'autovalue' to TemplateData

https://gerrit.wikimedia.org/r/146396",task_subcomment,"Change 146396 merged by jenkins-bot:
Add 'autovalue' to TemplateData

GERRIT_URL",ACTION ON ISSUE
234964,"VisualEditor: Template parameters with ""autofill"" TemplateData status should be autofilled","Change 146396 had a related patch set uploaded by Jforrester:
[wip] Add 'autovalue' to TemplateData

https://gerrit.wikimedia.org/r/146396",task_subcomment,"Change 146396 had a related patch set uploaded by Jforrester:
[wip] Add 'autovalue' to TemplateData

GERRIT_URL",ACTION ON ISSUE
234959,"VisualEditor: Template parameters with ""autofill"" TemplateData status should be autofilled","That's not the meaning of the ""default"" flag on parameters, but of the proposed ""autofill"" concept from bug 51428; relabelling for clarity.",task_subcomment,"That's not the meaning of the ""default"" flag on parameters, but of the proposed ""autofill"" concept from bug 51428; relabelling for clarity.",SOLUTION DISCUSSION
54014,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,"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",task_description,"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",BUG REPRODUCTION
233509,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,Merged and deployed.,task_subcomment,Merged and deployed.,TASK PROGRESS
233504,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,"Change 76241 merged by jenkins-bot:
ve.ui.Toolbar: Refactor floating logic for performance

https://gerrit.wikimedia.org/r/76241",task_subcomment,"Change 76241 merged by jenkins-bot:
ve.ui.Toolbar: Refactor floating logic for performance

GERRIT_URL",SOLUTION USAGE
233499,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,"Change 76241 had a related patch set uploaded by Jforrester:
ve.ui.Toolbar: Refactor floating logic for performance

https://gerrit.wikimedia.org/r/76241",task_subcomment,"Change 76241 had a related patch set uploaded by Jforrester:
ve.ui.Toolbar: Refactor floating logic for performance

GERRIT_URL",SOLUTION DISCUSSION
233493,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,https://gerrit.wikimedia.org/r/#/c/76241/,task_subcomment,URL,ACTION ON ISSUE
233486,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,"(In reply to comment #1)
> @Krinkle: How are you going to fix this? :-)

 I already did, in a way. Earlier this week I re-used that logic for mw.notification (which now also has a floating mode, previously mw.notify messages weren't visible if you scroll down the page, which is a problem for VE). However I noticed a few things that could be optimised that I did 'right' from the get go for mw.notify. I should be able to apply that to ve as well
 most notably the fact that floating calculation for ve toolbar calls offset() each time
 which is a repaint for something that is unlikely to ever change
 I realised it when I was doing mwnotify but never remembered to fix it in VE",task_subcomment,"(In reply to comment #1)
QUOTE

 I already did, in a way. Earlier this week I re-used that logic for mw.notification (which now also has a floating mode, previously mw.notify messages weren't visible if you scroll down the page, which is a problem for VE). However I noticed a few things that could be optimised that I did 'right' from the get go for mw.notify. I should be able to apply that to ve as well
 most notably the fact that floating calculation for ve toolbar calls offset() each time
 which is a repaint for something that is unlikely to ever change
 I realised it when I was doing mwnotify but never remembered to fix it in VE",SOLUTION DISCUSSION
233477,VisualEditor: floating toolbar causes scrolling of large pages to be very slow,@Krinkle: How are you going to fix this? :-),task_subcomment,SCREEN_NAME: How are you going to fix this? :-),SOLUTION DISCUSSION
54013,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"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",task_description,"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",BUG REPRODUCTION
233454,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,Merged and deployed.,task_subcomment,Merged and deployed.,TASK PROGRESS
233447,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Change 76110 merged by jenkins-bot:
Speed up openAndCloseAnnotations by using store indexes

https://gerrit.wikimedia.org/r/76110",task_subcomment,"Change 76110 merged by jenkins-bot:
Speed up openAndCloseAnnotations by using store indexes

GERRIT_URL",SOLUTION USAGE
233439,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Change 76100 merged by jenkins-bot:
Quick optimisation to avoid containsComparableForSerialization

https://gerrit.wikimedia.org/r/76100",task_subcomment,"Change 76100 merged by jenkins-bot:
Quick optimisation to avoid containsComparableForSerialization

GERRIT_URL",ACTION ON ISSUE
233434,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,With these two patches ^^^ getDomFromData has sped up from 1150ms to 180ms on my local copy of en:Argentina.,task_subcomment,With these two patches ^^^ getDomFromData has sped up from 1150ms to 180ms on my local copy of en:Argentina.,SOLUTION DISCUSSION
233430,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Change 76110 had a related patch set uploaded by Esanders:
Further annotation optimisations

https://gerrit.wikimedia.org/r/76110",task_subcomment,"Change 76110 had a related patch set uploaded by Esanders:
Further annotation optimisations

GERRIT_URL",SOLUTION DISCUSSION
233426,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Change 76100 had a related patch set uploaded by Esanders:
Quick optimisation to avoid containsComparableForSerialization

https://gerrit.wikimedia.org/r/76100",task_subcomment,"Change 76100 had a related patch set uploaded by Esanders:
Quick optimisation to avoid containsComparableForSerialization

GERRIT_URL",SOLUTION USAGE
233421,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"(In reply to comment #5)
> Even further suggestion from Tim: make the IVStore use a binary search tree,
> where the nodes are something like { index: number, value: Object } and the
> comparison operates on the objects, something similar to oo.compare() but
> returns < or >. This requires an ordering on the keys. We could do alphabetic
> order like in keySortReplacer, but it would be more efficient to have the
> ve.dm.Annotation object return an ordering on the keys. Or something. This is
> an incomplete thought and requires experimentation.

The point of this would be to reduce the memory usage of IVStore by eliminating the duplication caused by using the JSON as a key, and also to reduce the CPU overhead of ve.getHash(). But note that neither of these things are confirmed as performance issues in the profiling I have done so far.

In any case, comparison of store indexes would obviously be faster than binary search followed by value comparison. So I think index comparison should be the priority, of the ideas discussed here, assuming it can be implemented in such a way that pressing backspace on plain text will predominantly hit index comparison rather than value comparison. After that is implemented, we can do more profiling and decide whether the use of ve.getHash() is a problem worthy of significant development time.",task_subcomment,"(In reply to comment #5)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

The point of this would be to reduce the memory usage of IVStore by eliminating the duplication caused by using the JSON as a key, and also to reduce the CPU overhead of ve.getHash(). But note that neither of these things are confirmed as performance issues in the profiling I have done so far.

In any case, comparison of store indexes would obviously be faster than binary search followed by value comparison. So I think index comparison should be the priority, of the ideas discussed here, assuming it can be implemented in such a way that pressing backspace on plain text will predominantly hit index comparison rather than value comparison. After that is implemented, we can do more profiling and decide whether the use of ve.getHash() is a problem worthy of significant development time.",SOLUTION DISCUSSION
233415,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"(In reply to comment #3)
> Suggestion from IRC, posting to the bug for prosperity:

s/prosperity/posterity/ ;-)

[cf. bug 49198 comment 5]",task_subcomment,"(In reply to comment #3)
QUOTE

s/prosperity/posterity/ ;-)

[cf. bug 49198 comment 5]",ACTION ON ISSUE
233411,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Even further suggestion from Tim: make the IVStore use a binary search tree, where the nodes are something like { index: number, value: Object } and the comparison operates on the objects, something similar to oo.compare() but returns < or >. This requires an ordering on the keys. We could do alphabetic order like in keySortReplacer, but it would be more efficient to have the ve.dm.Annotation object return an ordering on the keys. Or something. This is an incomplete thought and requires experimentation.

Giving this to Ed because he's a machine that turns vague incomplete suggestions into working code and fixes a few bugs in the process too ;)",task_subcomment,"Even further suggestion from Tim: make the IVStore use a binary search tree, where the nodes are something like { index: number, value: Object } and the comparison operates on the objects, something similar to oo.compare() but returns < or >. This requires an ordering on the keys. We could do alphabetic order like in keySortReplacer, but it would be more efficient to have the ve.dm.Annotation object return an ordering on the keys. Or something. This is an incomplete thought and requires experimentation.

Giving this to Ed because he's a machine that turns vague incomplete suggestions into working code and fixes a few bugs in the process too ;)",SOLUTION DISCUSSION
233408,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Further suggestion: when we're comparing annotations, try to compare store indexes wherever possible. When we're comparing for identity, like when comparing for serialization when both annotations are generated, we could compare store indexes rather than using ve.compare(). And if we throw comparable objects into the store, we might be able to do index comparison there too.

Maybe ve.dm.Annotation instances should have properties that track the store index of their this.element and their comparable objects?

Ed, could you play with this?",task_subcomment,"Further suggestion: when we're comparing annotations, try to compare store indexes wherever possible. When we're comparing for identity, like when comparing for serialization when both annotations are generated, we could compare store indexes rather than using ve.compare(). And if we throw comparable objects into the store, we might be able to do index comparison there too.

Maybe ve.dm.Annotation instances should have properties that track the store index of their this.element and their comparable objects?

Ed, could you play with this?",SOLUTION DISCUSSION
233404,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"Suggestion from IRC, posting to the bug for prosperity:

[15:12]	 TimStarling: As a hack, could you try to set ve.compare = function ( a, b ) { return ve.getHash( a ) === ve.getHash( b ); }; instead of ve.compare = oo.compare; (in ve.js) and see how much that mitigates the problem?",task_subcomment,"Suggestion from IRC, posting to the bug for prosperity:

[15:12]	 TimStarling: As a hack, could you try to set ve.compare = function ( a, b ) { return ve.getHash( a ) === ve.getHash( b ); }; instead of ve.compare = oo.compare; (in ve.js) and see how much that mitigates the problem?",SOLUTION DISCUSSION
233398,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"(In reply to comment #1)
> In both actions, on my favourite test case for today ([[Argentina]]), about
> 10s of CPU usage is attributable to openAndCloseAnnotations(), and about 80%
> of that is from oo.compare().

Perhaps related to bug 51948.",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE
QUOTE

Perhaps related to bug 51948.",MOTIVATION
233391,VisualEditor: Deleting plain text from a large page with backspace or delete is very slow,"The slowness of ve.dm.Converter.openAndCloseAnnotations() also dominates the performance of ve.dm.Converter.prototype.getDomFromData(), severely affecting both initial setup and ""review changes"". In both actions, on my favourite test case for today ([[Argentina]]), about 10s of CPU usage is attributable to openAndCloseAnnotations(), and about 80% of that is from oo.compare().",task_subcomment,"The slowness of ve.dm.Converter.openAndCloseAnnotations() also dominates the performance of ve.dm.Converter.prototype.getDomFromData(), severely affecting both initial setup and ""review changes"". In both actions, on my favourite test case for today ([[Argentina]]), about 10s of CPU usage is attributable to openAndCloseAnnotations(), and about 80% of that is from oo.compare().",BUG REPRODUCTION
54004,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"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",task_description,"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**:
URL
URL
URL
URL",BUG REPRODUCTION
232641,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"Change 119204 merged by jenkins-bot:
Show blockedtext message in edit notices

https://gerrit.wikimedia.org/r/119204",task_subcomment,"Change 119204 merged by jenkins-bot:
Show blockedtext message in edit notices

GERRIT_URL",ACTION ON ISSUE
232635,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"Change 119204 had a related patch set uploaded by Alex Monk:
Show blockedtext message in edit notices

https://gerrit.wikimedia.org/r/119204",task_subcomment,"Change 119204 had a related patch set uploaded by Alex Monk:
Show blockedtext message in edit notices

GERRIT_URL",ACTION ON ISSUE
232630,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"(In reply to Roan Kattouw from comment #4)
> We already put random junk in the paction=parse response, I wouldn't be
> opposed to adding blocked-ness to that. Another paction would be OK too, but
> then we'd have to make two API requests.
> 
> There are significant speed benefits in combining everything into one API
> request. I think we should stop kidding ourselves that paction=parse is a
> clean, only-does-one-thing action, and perhaps rename it if we want, rather
> than trying to split it into separate actions, because the latter would just
> make client-side performance worse.

Yes, since writing that comment I decided to just add it in to paction=parse, especially since talking to James - he wants this to be an edit notice like the others. I probably should have left a new comment about it.

The problem now is coming up with a nice way to fit the autoblockedtext message (blockedtext is okay) in to the edit notices popup.",task_subcomment,"(In reply to Roan Kattouw from comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Yes, since writing that comment I decided to just add it in to paction=parse, especially since talking to James - he wants this to be an edit notice like the others. I probably should have left a new comment about it.

The problem now is coming up with a nice way to fit the autoblockedtext message (blockedtext is okay) in to the edit notices popup.",ACTION ON ISSUE
232627,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"(In reply to Alex Monk from comment #3)
> James suggested I tackle this bug. I messed around with the API for a little
> bit and assuming I didn't miss anything:
> 
> I think that if we tried to fill out the 'blockedtext' message properly on
> the client we'd have to:
> * Query the API for the user's blockinfo to determine whether or not they're
> blocked. If they are:
> ** Query the API for more info about this block which
> meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute
> into the message (expiry, user, timestamp).
> ** Query the API to parse the blockedtext message because it can't be done
> on the client (even the default message includes stuff mw.msg can't handle)
> ** Substitute the data we have into the message (and we still won't have $3
> - the current IP)
> *** Mess around with dates/times because they won't be in the right format.
> 
> Another way we could do this is return the full warning from
> action=visualeditor&paction=parse (therefore adding no extra API requests)
> which would cause the client to stop loading. I don't like this idea because
> obviously that paction is not intended for checking this kind of thing...
> 
> Or we could ignore the core blockedtext message and use our own ""Your
> username or IP address has been blocked"", possibly with the info that just
> meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).
> 
> Or we could add a new API module/paction that can be queried once and
> provides all the relevant info. I don't like this idea either but it seems
> the nicest.
> 
We already put random junk in the paction=parse response, I wouldn't be opposed to adding blocked-ness to that. Another paction would be OK too, but then we'd have to make two API requests.

There are significant speed benefits in combining everything into one API request. I think we should stop kidding ourselves that paction=parse is a clean, only-does-one-thing action, and perhaps rename it if we want, rather than trying to split it into separate actions, because the latter would just make client-side performance worse.",task_subcomment,"(In reply to Alex Monk from comment #3)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
We already put random junk in the paction=parse response, I wouldn't be opposed to adding blocked-ness to that. Another paction would be OK too, but then we'd have to make two API requests.

There are significant speed benefits in combining everything into one API request. I think we should stop kidding ourselves that paction=parse is a clean, only-does-one-thing action, and perhaps rename it if we want, rather than trying to split it into separate actions, because the latter would just make client-side performance worse.",SOLUTION DISCUSSION
232624,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"James suggested I tackle this bug. I messed around with the API for a little bit and assuming I didn't miss anything:

I think that if we tried to fill out the 'blockedtext' message properly on the client we'd have to:
* Query the API for the user's blockinfo to determine whether or not they're blocked. If they are:
** Query the API for more info about this block which meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute into the message (expiry, user, timestamp).
** Query the API to parse the blockedtext message because it can't be done on the client (even the default message includes stuff mw.msg can't handle)
** Substitute the data we have into the message (and we still won't have $3 - the current IP)
*** Mess around with dates/times because they won't be in the right format.

Another way we could do this is return the full warning from action=visualeditor&paction=parse (therefore adding no extra API requests) which would cause the client to stop loading. I don't like this idea because obviously that paction is not intended for checking this kind of thing...

Or we could ignore the core blockedtext message and use our own ""Your username or IP address has been blocked"", possibly with the info that just meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).

Or we could add a new API module/paction that can be queried once and provides all the relevant info. I don't like this idea either but it seems the nicest.

Thoughts?",task_subcomment,"James suggested I tackle this bug. I messed around with the API for a little bit and assuming I didn't miss anything:

I think that if we tried to fill out the 'blockedtext' message properly on the client we'd have to:
* Query the API for the user's blockinfo to determine whether or not they're blocked. If they are:
** Query the API for more info about this block which meta=userinfo&uiprop=blockinfo doesn't provide but we need to substitute into the message (expiry, user, timestamp).
** Query the API to parse the blockedtext message because it can't be done on the client (even the default message includes stuff mw.msg can't handle)
** Substitute the data we have into the message (and we still won't have $3 - the current IP)
*** Mess around with dates/times because they won't be in the right format.

Another way we could do this is return the full warning from action=visualeditor&paction=parse (therefore adding no extra API requests) which would cause the client to stop loading. I don't like this idea because obviously that paction is not intended for checking this kind of thing...

Or we could ignore the core blockedtext message and use our own ""Your username or IP address has been blocked"", possibly with the info that just meta=userinfo&uiprop=blockinfo provides (block ID, performer, reason).

Or we could add a new API module/paction that can be queried once and provides all the relevant info. I don't like this idea either but it seems the nicest.

Thoughts?",SOLUTION DISCUSSION
232621,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"Created attachment 12954
What a blocked user sees immediately they the source editor loads

**Attached**: {F11061}",task_subcomment,"Created attachment 12954
What a blocked user sees immediately they the source editor loads

**Attached**: {F11061}",ACTION ON ISSUE
232615,VisualEditor: Blocked users are not blocked from using VE (just from saving); should instead show  with log entry,"Created attachment 12953
What a blocked user sees when they try to save an edit in VE

**Attached**: {F11060}",task_subcomment,"Created attachment 12953
What a blocked user sees when they try to save an edit in VE

**Attached**: {F11060}",ACTION ON ISSUE
54000,VisualEditor: Can't re-use a reference belonging to non-default group,"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",task_description,"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**:
URL",BUG REPRODUCTION
232338,VisualEditor: Can't re-use a reference belonging to non-default group,"Change 81964 merged by jenkins-bot:
Re-build reference search index so they can be used mid-edit

https://gerrit.wikimedia.org/r/81964",task_subcomment,"Change 81964 merged by jenkins-bot:
Re-build reference search index so they can be used mid-edit

GERRIT_URL",ACTION ON ISSUE
232332,VisualEditor: Can't re-use a reference belonging to non-default group,Now fixed in master and will be deployed next week.,task_subcomment,Now fixed in master and will be deployed next week.,TASK PROGRESS
232323,VisualEditor: Can't re-use a reference belonging to non-default group,"Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 51689 & 52000 - Reusing new references

https://gerrit.wikimedia.org/r/81964",task_subcomment,"Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 51689 & 52000 - Reusing new references

GERRIT_URL",SOLUTION USAGE
232316,VisualEditor: Can't re-use a reference belonging to non-default group,"Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 52000 - Reusing new reference groups

https://gerrit.wikimedia.org/r/81964",task_subcomment,"Change 81964 had a related patch set uploaded by Trevor Parscal:
Bug 52000 - Reusing new reference groups

GERRIT_URL",SOLUTION USAGE
232311,VisualEditor: Can't re-use a reference belonging to non-default group,"This works if the group exists when VE loads the page, but if the group is added after load then it's items don't show up in the search.",task_subcomment,"This works if the group exists when VE loads the page, but if the group is added after load then it's items don't show up in the search.",BUG REPRODUCTION
53999,VisualEditor: Saving fails silently for some blocked users,"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",task_description,"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**:
URL",BUG REPRODUCTION
232271,VisualEditor: Saving fails silently for some blocked users,This was fixed in the fix for bug 52004.,task_subcomment,This was fixed in the fix for bug 52004.,SOLUTION USAGE
232260,VisualEditor: Saving fails silently for some blocked users,"The original reporter, numbermaniac, has done some additional testing and found that they do see the message when pressing save in Chrome on Windows 7. Their initial report was using iMac Safari.

My testing was done using Firefox 22 on Xubuntu Linux",task_subcomment,"The original reporter, numbermaniac, has done some additional testing and found that they do see the message when pressing save in Chrome on Windows 7. Their initial report was using iMac Safari.

My testing was done using Firefox 22 on Xubuntu Linux",BUG REPRODUCTION
53995,VisualEditor: Thumb images are missing appropriate CSS classes,"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",task_description,"For instance instead of class 'tright' or 'tleft' just class 't' gets added. It is regression of this change: URL

--------------------------
**Version**: unspecified
**Severity**: normal",BUG REPRODUCTION
232089,VisualEditor: Thumb images are missing appropriate CSS classes,Now fixed in master and will be deployed in a few minutes' time.,task_subcomment,Now fixed in master and will be deployed in a few minutes' time.,SOLUTION USAGE
232087,VisualEditor: Thumb images are missing appropriate CSS classes,"Change 75803 merged by jenkins-bot:
Fix MWBlockImageNodes' default horizontal location code

https://gerrit.wikimedia.org/r/75803",task_subcomment,"Change 75803 merged by jenkins-bot:
Fix MWBlockImageNodes' default horizontal location code

GERRIT_URL",SOLUTION USAGE
232084,VisualEditor: Thumb images are missing appropriate CSS classes,"Change 75803 had a related patch set uploaded by Jforrester:
(bug 51995) Bugfix

https://gerrit.wikimedia.org/r/75803",task_subcomment,"Change 75803 had a related patch set uploaded by Jforrester:
(bug 51995) Bugfix

GERRIT_URL",ACTION ON ISSUE
232080,VisualEditor: Thumb images are missing appropriate CSS classes,"Change 75803 had a related patch set uploaded by Inez:
(bug 51995) Bugfix

https://gerrit.wikimedia.org/r/75803",task_subcomment,"Change 75803 had a related patch set uploaded by Inez:
(bug 51995) Bugfix

GERRIT_URL",ACTION ON ISSUE
53987,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),"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}",task_description,"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}",BUG REPRODUCTION
255102,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),"Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",task_subcomment,"Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",EXPECTED BEHAVIOR
255097,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),"(In reply to comment #3)
> Cannot reproduce it now with MAC OS using FireFox and Chrome.

Please ALWAYS provide version information for browsers. 
Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".

> So changing the status of the bug as resolved.

No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",task_subcomment,"(In reply to comment #3)
QUOTE

Please ALWAYS provide version information for browsers. 
Note that comment 0 says ""Tested on both Firefox 22 and Chrome 28"".

QUOTE

No identifiable code commit, hence changing to WORKSFORME instead of FIXED. Also see URL",ACTION ON ISSUE
255092,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),"Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.
If you can still reproduce it ,please reopen the bug.",task_subcomment,"Cannot reproduce it now with MAC OS using FireFox and Chrome.So changing the status of the bug as resolved.
If you can still reproduce it ,please reopen the bug.",BUG REPRODUCTION
255087,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?),task_subcomment,This is an infinite loop inside either Rangy or the bit of ContentEditable that calls it - lots of calls to sel.getRangeAt(index) which end up taking so long that the browser dies (?),BUG REPRODUCTION
255082,VisualEditor: Infinite loop (browser lockup) when removing an initial list item with a node inside it (rangy bug?),We should have a 'crash' or 'dataloss' keyword.  Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.,task_subcomment,We should have a 'crash' or 'dataloss' keyword.  Bumping priority to get more attention/triaging in case the underlying cause is able to be triggered in other ways.,BUG REPRODUCTION
53986,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","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",task_description,"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**: URL",BUG REPRODUCTION
255045,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown",This is now fixed in master; we will make sure it is deployed tomorrow.,task_subcomment,This is now fixed in master; we will make sure it is deployed tomorrow.,SOLUTION USAGE
255041,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Change 75785 merged by jenkins-bot:
Fix the save button disappearing on certain pages in Firefox

https://gerrit.wikimedia.org/r/75785",task_subcomment,"Change 75785 merged by jenkins-bot:
Fix the save button disappearing on certain pages in Firefox

GERRIT_URL",ACTION ON ISSUE
255034,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Change 75785 had a related patch set uploaded by Catrope:
Fix the save button disappearing on certain pages in Firefox

https://gerrit.wikimedia.org/r/75785",task_subcomment,"Change 75785 had a related patch set uploaded by Catrope:
Fix the save button disappearing on certain pages in Firefox

GERRIT_URL",ACTION ON ISSUE
255026,"VisualEditor: Action buttons of the toolbar (including ""Save"") don't appear on some articles in Firefox because error is thrown","Another article where this happens:

https://he.wikipedia.org/wiki/%D7%A4%D7%9C%D7%99%D7%98%D7%99_%D7%9E%D7%9C%D7%97%D7%9E%D7%AA_%D7%94%D7%90%D7%96%D7%A8%D7%97%D7%99%D7%9D_%D7%91%D7%A1%D7%95%D7%A8%D7%99%D7%94?veaction=edit",task_subcomment,"Another article where this happens:

URL",BUG REPRODUCTION
53984,VisualEditor: Clicking the hyper link button twice breaks the button.,"(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",task_description,"(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",BUG REPRODUCTION
254940,VisualEditor: Clicking the hyper link button twice breaks the button.,"

*** This bug has been marked as a duplicate of bug 51404 ***",task_subcomment,"

*** This bug has been marked as a duplicate of bug 51404 ***",ACTION ON ISSUE
254935,VisualEditor: Clicking the hyper link button twice breaks the button.,"most likely duplicate of bug 51404, which should be subsequently renamed from ""crashing when inserting link without selection"" to ""crashing when inserting link on non-linkable or empty selection""",task_subcomment,"most likely duplicate of bug 51404, which should be subsequently renamed from ""crashing when inserting link without selection"" to ""crashing when inserting link on non-linkable or empty selection""",BUG REPRODUCTION
254930,VisualEditor: Clicking the hyper link button twice breaks the button.,"Addendum:
After some more testing it would seem that the link button will always break whenever the user selects an element that normally wouldn't be hyperlinked. If one does select a non linkable element and presses the hyperlink button the empty balloon popup will always occur.  

These elements include - among others - images, templates, references and objects that cannot be edited in the visual editor yet. Unfortunately there seems to be no way restore the link buttons functionality without reloading the editor itself.",task_subcomment,"Addendum:
After some more testing it would seem that the link button will always break whenever the user selects an element that normally wouldn't be hyperlinked. If one does select a non linkable element and presses the hyperlink button the empty balloon popup will always occur.  

These elements include - among others - images, templates, references and objects that cannot be edited in the visual editor yet. Unfortunately there seems to be no way restore the link buttons functionality without reloading the editor itself.",BUG REPRODUCTION
254925,VisualEditor: Clicking the hyper link button twice breaks the button.,I was able to reproduce following the steps in comment 3.,task_subcomment,I was able to reproduce following the steps in comment 3.,BUG REPRODUCTION
254918,VisualEditor: Clicking the hyper link button twice breaks the button.,"Chrome 28 - Error console

And last: A screenshot of chrome's console. It seems to be a tad more in depth than the error Firefox displays.

**Attached**: {F11891}",task_subcomment,"Chrome 28 - Error console

And last: A screenshot of chrome's console. It seems to be a tad more in depth than the error Firefox displays.

**Attached**: {F11891}",BUG REPRODUCTION
254911,VisualEditor: Clicking the hyper link button twice breaks the button.,"Yep, one pops up on step 3:

[23:46:29.770] Error: No class registered by that name: undefined @ https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130724T164530Z&*:2

The above screenshot displays what occurs on the page. Also, a more specific set of steps that might help to reproduce this:

1) Edit the [[Portland Ice Arena (Oregon)]] page in the visual editor.
2) Place the cursor directly after reference [2]. 
3) Click the hyperlink button. It should create the regular hyperlink balloon as seen in the left side of the attached screenshot.
4) Click the 'Not to be confused with Portland Ice Arena (Maine).' template. This will cause the template to ""blank"" itself as seen in the right side of the screenshot. 
5) Click the 'Not to be confused with Portland Ice Arena (Maine).' template another time. This will cause the empty edit balloon to disappear. 
6) Try the edit link button anywhere in the page itself - it will no longer work (Not on existing links nor on new ones)

Note that it is not required to click the template - clicking elsewhere will work as well.",task_subcomment,"Yep, one pops up on step 3:

[23:46:29.770] Error: No class registered by that name: undefined @ URL

The above screenshot displays what occurs on the page. Also, a more specific set of steps that might help to reproduce this:

1) Edit the [[Portland Ice Arena (Oregon)]] page in the visual editor.
2) Place the cursor directly after reference [2]. 
3) Click the hyperlink button. It should create the regular hyperlink balloon as seen in the left side of the attached screenshot.
4) Click the 'Not to be confused with Portland Ice Arena (Maine).' template. This will cause the template to ""blank"" itself as seen in the right side of the screenshot. 
5) Click the 'Not to be confused with Portland Ice Arena (Maine).' template another time. This will cause the empty edit balloon to disappear. 
6) Try the edit link button anywhere in the page itself - it will no longer work (Not on existing links nor on new ones)

Note that it is not required to click the template - clicking elsewhere will work as well.",BUG REPRODUCTION
254906,VisualEditor: Clicking the hyper link button twice breaks the button.,"Error screenshot.

**Attached**: {F11890}",task_subcomment,"Error screenshot.

**Attached**: {F11890}",BUG REPRODUCTION
254902,VisualEditor: Clicking the hyper link button twice breaks the button.,I can't reproduce this. Do you see any errors in your JS console?,task_subcomment,I can't reproduce this. Do you see any errors in your JS console?,BUG REPRODUCTION
53978,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"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",task_description,"The Hebrew Wikipedia frequently uses the template {{כ}} ( URL ), 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 URL .

--------------------------
**Version**: unspecified
**Severity**: normal
**URL**: URL",BUG REPRODUCTION
254594,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"(In reply to Amir E. Aharoni from comment #6)
> At Wikimania Moriel, Roan and I found that the bug, as originally reported,
> appears to be fixed. I don't know when exactly did the fix happen.
> 
> Using the {{כ}} template works correctly while editing articles, and the
> original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows
> everything correctly.

This would probably have been fixed by Ed's work on unwrapping generated content nodes.

> That said, there are issues with handling this template after it's inserted:
> * The bubble that shows its name appears in a wrong location.

Yeah, the context seems to find the nearest thing that actually displays and attaches to that. Probably the same issue as the below.

> * It's hard to know that it's there while editing in visual mode, because it
> is zero-width. Showing some kind of a flag there, as it's done with single
> line breaks, would be a nice idea.

That's bug 49806.

> Should I close this bug and open separate bugs for these issues?

Have done so. Yay.",task_subcomment,"(In reply to Amir E. Aharoni from comment #6)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

This would probably have been fixed by Ed's work on unwrapping generated content nodes.

QUOTE
QUOTE

Yeah, the context seems to find the nearest thing that actually displays and attaches to that. Probably the same issue as the below.

QUOTE
QUOTE
QUOTE

That's bug 49806.

QUOTE

Have done so. Yay.",ACTION ON ISSUE
254590,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"At Wikimania Moriel, Roan and I found that the bug, as originally reported, appears to be fixed. I don't know when exactly did the fix happen.

Using the {{כ}} template works correctly while editing articles, and the original test page https://he.wikipedia.org/wiki/User:Amire80/ve-rlm shows everything correctly.

That said, there are issues with handling this template after it's inserted:
* The bubble that shows its name appears in a wrong location.
* It's hard to know that it's there while editing in visual mode, because it is zero-width. Showing some kind of a flag there, as it's done with single line breaks, would be a nice idea.

Should I close this bug and open separate bugs for these issues?",task_subcomment,"At Wikimania Moriel, Roan and I found that the bug, as originally reported, appears to be fixed. I don't know when exactly did the fix happen.

Using the {{כ}} template works correctly while editing articles, and the original test page URL shows everything correctly.

That said, there are issues with handling this template after it's inserted:
* The bubble that shows its name appears in a wrong location.
* It's hard to know that it's there while editing in visual mode, because it is zero-width. Showing some kind of a flag there, as it's done with single line breaks, would be a nice idea.

Should I close this bug and open separate bugs for these issues?",SOLUTION DISCUSSION
254586,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"(In reply to comment #4)
> 2. Language definition to assign directionality rather than RLM is good
> approach, but it isn't possible to replace all the RLM uses:
> A. for normal users it is annoying to meet wiki-text editing HTML code of
>  dir="""">...

That's why Moriel invested so much time in an easy graphical way to do it :)

It's still in the ""finishing touches"" stage.

The trouble is that while bidi isolation replaces most or all of the uses of RLM, it doesn't work in IE. Saw it coming? :)

In fact, IE 10 and 11 (!) even show some elements with bidi isolation very incorrectly. Test the following page:
https://en.wikipedia.org/wiki/User:Amire80/bidi-isolate

> Regarding the issue of ""invisible template"" which the VE users don't know it
> is
> there - I think it will be nice (and maybe there is already exist) to add
> ability to add text that appears only in VE editing mode [either with CSS
> which
> tells the content to display:none, and only in VE it appears, or with
> dedicated
> parser tag . This solution may be useful for other cases of
> ""invisible
> templates"".

I love this proposal.",task_subcomment,"(In reply to comment #4)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That's why Moriel invested so much time in an easy graphical way to do it :)

It's still in the ""finishing touches"" stage.

The trouble is that while bidi isolation replaces most or all of the uses of RLM, it doesn't work in IE. Saw it coming? :)

In fact, IE 10 and 11 (!) even show some elements with bidi isolation very incorrectly. Test the following page:
URL

QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

I love this proposal.",ACTION ON ISSUE
254583,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"1. I think that adding display:inline-block by the VE (to any transclusion node - and particularly to this template)  is a bug, We should consider either removing this css or changing it to inline instead of inline-block
2. Language definition to assign directionality rather than RLM is good approach, but it isn't possible to replace all the RLM uses:
A. for normal users it is annoying to meet wiki-text editing HTML code of ...
B. Sometimes specifying direction/language is overkill and the simple and best solution is to use RLM. 

Regarding the issue of ""invisible template"" which the VE users don't know it is there - I think it will be nice (and maybe there is already exist) to add ability to add text that appears only in VE editing mode [either with CSS which tells the content to display:none, and only in VE it appears, or with dedicated parser tag . This solution may be useful for other cases of ""invisible templates"".",task_subcomment,"1. I think that adding display:inline-block by the VE (to any transclusion node - and particularly to this template)  is a bug, We should consider either removing this css or changing it to inline instead of inline-block
2. Language definition to assign directionality rather than RLM is good approach, but it isn't possible to replace all the RLM uses:
A. for normal users it is annoying to meet wiki-text editing HTML code of ...
B. Sometimes specifying direction/language is overkill and the simple and best solution is to use RLM. 

Regarding the issue of ""invisible template"" which the VE users don't know it is there - I think it will be nice (and maybe there is already exist) to add ability to add text that appears only in VE editing mode [either with CSS which tells the content to display:none, and only in VE it appears, or with dedicated parser tag . This solution may be useful for other cases of ""invisible templates"".",SOLUTION DISCUSSION
254578,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"This is a bit more complicated than removing a css definition.

As far as I understand this is what happens -- 

1. Parsoid recognizes {{כ}} as a template (expected) and sends it to VE as a transclusion object. 
2. VE treats it as transclusion object (as expected) --- but this means that-
3. The content of the transclusion/template is wrapped with transclusion node markup. This means that the RLM code is now wrapped with html markup, which effectively alienates it from the string it is supposed to affect.

In most other templates the above behavior is exactly what we want, so this template is an exception. We need to figure out a way to recognize these exceptional templates and then deal with them.

But there is another issue - this is going to be a design challenge, too. 

""RLM"" is an invisible character, so when we look at the article itself we have no indication that there is any special notation or character inside a sentence or a word. So, when we let users edit this in VisualEditor, we have to see how we can allow RLM to affect the word (so, it needs to not be encapsulated with html) *but* we also have to make sure a user can see it is there and, hopefully, interact with it.

We need to come up with creative ways on how to allow user interaction. 

What happens, for example, if a user removes the string the RLM was attached to without removing the RLM character itself? The user may not know about it if it is invisible, and it can cause problems in the edit and later edit in that sentence.


I think we might want to consider shifting from RLM templates, that provide directionality change in a string, to language annotations, that provide the same thing *plus* language definition. This is what we're moving towards anyways. It provides more information and it lets the user interact with the language definition. 

I understand that if we do it we will get dirty diffs, but I am not entirely sure how we can deal with RLM properly in the editor -- and is it not in any case preferable to use full-information language annotation instead of a limited-behavior RLM character?",task_subcomment,"This is a bit more complicated than removing a css definition.

As far as I understand this is what happens -- 

1. Parsoid recognizes {{כ}} as a template (expected) and sends it to VE as a transclusion object. 
2. VE treats it as transclusion object (as expected) --- but this means that-
3. The content of the transclusion/template is wrapped with transclusion node markup. This means that the RLM code is now wrapped with html markup, which effectively alienates it from the string it is supposed to affect.

In most other templates the above behavior is exactly what we want, so this template is an exception. We need to figure out a way to recognize these exceptional templates and then deal with them.

But there is another issue - this is going to be a design challenge, too. 

""RLM"" is an invisible character, so when we look at the article itself we have no indication that there is any special notation or character inside a sentence or a word. So, when we let users edit this in VisualEditor, we have to see how we can allow RLM to affect the word (so, it needs to not be encapsulated with html) *but* we also have to make sure a user can see it is there and, hopefully, interact with it.

We need to come up with creative ways on how to allow user interaction. 

What happens, for example, if a user removes the string the RLM was attached to without removing the RLM character itself? The user may not know about it if it is invisible, and it can cause problems in the edit and later edit in that sentence.


I think we might want to consider shifting from RLM templates, that provide directionality change in a string, to language annotations, that provide the same thing *plus* language definition. This is what we're moving towards anyways. It provides more information and it lets the user interact with the language definition. 

I understand that if we do it we will get dirty diffs, but I am not entirely sure how we can deal with RLM properly in the editor -- and is it not in any case preferable to use full-information language annotation instead of a limited-behavior RLM character?",SOLUTION DISCUSSION
254573,VisualEditor: A template with the RLM control character doesn't work when editing in VE,"Hint: when disabling inline-block display for the template 
(e.g removing:
.ve-ce-mwTransclusionInlineNode {
    display: inline-block;
}
)
it behaves properly.",task_subcomment,"Hint: when disabling inline-block display for the template 
(e.g removing:
.ve-ce-mwTransclusionInlineNode {
    display: inline-block;
}
)
it behaves properly.",BUG REPRODUCTION
254567,VisualEditor: A template with the RLM control character doesn't work when editing in VE,See https://he.wikipedia.org/wiki/User:Amire80/ve-rlm for a demostration.,task_subcomment,See URL for a demostration.,SOLUTION USAGE
53957,"VisualEditor: Firefox allows cursor to get into illegal position around wide objects (, , etc), leading to corruption, and prevents down arrow button navigation","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'  '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",task_description,"1. URL
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'  '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 URL , option (3) happens most often.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL
URL",BUG REPRODUCTION
253605,"VisualEditor: Firefox allows cursor to get into illegal position around wide objects (, , etc), leading to corruption, and prevents down arrow button navigation","I believe that this is now fixed, after the Firefox CE re-write, though I could be wrong – please re-open if so.",task_subcomment,"I believe that this is now fixed, after the Firefox CE re-write, though I could be wrong – please re-open if so.",ISSUE CONTENT MANAGEMENT
253601,"VisualEditor: Firefox allows cursor to get into illegal position around wide objects (, , etc), leading to corruption, and prevents down arrow button navigation","In addition to , and corruption, a less significant problem is that the down cursor becomes stuck at any block that consumes the entire page with (such as the references block or navbars); pressing the down arrow on the keyboard does not move the cursor to the next item underneath the block.

Steps to reproduce:
1. Load any page in VE with a references block and something underneath it. e.g.
   https://en.wikipedia.org/wiki/Jos%C3%A9_Cl%C3%A1udio_Ribeiro_da_Silva?veaction=edit
   https://en.wikipedia.org/wiki/Marty_Callaghan?veaction=edit

   or a similar block like in this article

   https://en.wikipedia.org/w/index.php?title=Mary_Louise_Smith_%28Republican_Party_leader%29&veaction=edit

2. Repeat pressing down key to reach the bottom of the article

Expected results:
Down key continues to step down through the article until it reaches the bottom.

Actual results:
Down key works until the references block.  It becomes stuck on the right hand side of the block.

Im adding this here as it appears to be the exact same underlying problem, as typing when the cursor is on the right-hand side of other wide objects, such as references, also produces unexpected results.",task_subcomment,"In addition to , and corruption, a less significant problem is that the down cursor becomes stuck at any block that consumes the entire page with (such as the references block or navbars); pressing the down arrow on the keyboard does not move the cursor to the next item underneath the block.

Steps to reproduce:
1. Load any page in VE with a references block and something underneath it. e.g.
   URL
   URL

   or a similar block like in this article

   URL

2. Repeat pressing down key to reach the bottom of the article

Expected results:
Down key continues to step down through the article until it reaches the bottom.

Actual results:
Down key works until the references block.  It becomes stuck on the right hand side of the block.

Im adding this here as it appears to be the exact same underlying problem, as typing when the cursor is on the right-hand side of other wide objects, such as references, also produces unexpected results.",BUG REPRODUCTION
253598,"VisualEditor: Firefox allows cursor to get into illegal position around wide objects (, , etc), leading to corruption, and prevents down arrow button navigation","Confirmed bug in Firefox. Specifically:

(In reply to comment #0)
> 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

No, it really shouldn't - it should be in the next heading (""Anzahl Bilder pro Reihe: perrow=2""). See the behaviour in Chrome/Safari for reference. This is a bug specific to Firefox AFAICT.",task_subcomment,"Confirmed bug in Firefox. Specifically:

(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE

No, it really shouldn't - it should be in the next heading (""Anzahl Bilder pro Reihe: perrow=2""). See the behaviour in Chrome/Safari for reference. This is a bug specific to Firefox AFAICT.",BUG REPRODUCTION
253595,"VisualEditor: Firefox allows cursor to get into illegal position around wide objects (, , etc), leading to corruption, and prevents down arrow button navigation","Reliable snowmen

1. https://de.wikipedia.org/wiki/Benutzer:John_Vandenberg/test?veaction=edit
2. Place the cursor above the image (which is inside a template)
3. press down so that the cursor is beside the image/template
4. press 'a'

Win: snowman + 'a'",task_subcomment,"Reliable snowmen

1. URL
2. Place the cursor above the image (which is inside a template)
3. press down so that the cursor is beside the image/template
4. press 'a'

Win: snowman + 'a'",SOLUTION USAGE
53933,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,"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}",task_description,"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**:
URL

**Attached**: {F11785}",BUG REPRODUCTION
252427,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,Both of the examples linked to work now.,task_subcomment,Both of the examples linked to work now.,SOLUTION USAGE
252422,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,Partially mitigated by the above but I believe not fixed. Resetting.,task_subcomment,Partially mitigated by the above but I believe not fixed. Resetting.,SOLUTION USAGE
252420,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,"Change 138338 merged by jenkins-bot:
Special case for shielding of generated content wrappers

https://gerrit.wikimedia.org/r/138338",task_subcomment,"Change 138338 merged by jenkins-bot:
Special case for shielding of generated content wrappers

GERRIT_URL",ACTION ON ISSUE
252416,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,"Change 138338 had a related patch set uploaded by Esanders:
Special case for shielding of generated content wrappers

https://gerrit.wikimedia.org/r/138338",task_subcomment,"Change 138338 had a related patch set uploaded by Esanders:
Special case for shielding of generated content wrappers

GERRIT_URL",ACTION ON ISSUE
252411,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,*** Bug 54301 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 54301 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
252405,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,*** Bug 50970 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 50970 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
252398,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,The edit icon showing up in random places is also mentioned at https://bugzilla.wikimedia.org/show_bug.cgi?id=51548 .,task_subcomment,The edit icon showing up in random places is also mentioned at URL .,BUG REPRODUCTION
252392,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,"*overlapping blocks, or templates, or whatever, you understood me :)",task_subcomment,"*overlapping blocks, or templates, or whatever, you understood me :)",SOLUTION DISCUSSION
252385,VisualEditor: Overlapping template boxes make some transclusions difficult or impossible to access,"I arrived here to document the same situation. A user at en.wp reports he's not able to edit reviews with VE at http://en.wikipedia.org/wiki/X_(Def_Leppard_album) because of the overlapping windows. While for me this is certainly the case with FF, with Chrome instead I am able to select the template if I click on the Review Scores line. This said, the icon to actually edit contents only appears... at the top of the Infobox album - definitely not where one would expect it to.",task_subcomment,"I arrived here to document the same situation. A user at en.wp reports he's not able to edit reviews with VE at URL because of the overlapping windows. While for me this is certainly the case with FF, with Chrome instead I am able to select the template if I click on the Review Scores line. This said, the icon to actually edit contents only appears... at the top of the Infobox album - definitely not where one would expect it to.",SOLUTION DISCUSSION
53918,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"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",task_description,"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",BUG REPRODUCTION
251362,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"At least for me, this is not browser-specific: I get the problem in both Chrome and FFox. (The other problem is, I agree, browser-specific.)",task_subcomment,"At least for me, this is not browser-specific: I get the problem in both Chrome and FFox. (The other problem is, I agree, browser-specific.)",MOTIVATION
251354,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"(In reply to Luis Villa (personal-for work use lvilla@wikimedia.org) from comment #11)
> This is broken (again?) The three license links come up before the action
> buttons (and save page never comes up, but that is bug 50047 I think?)

Was going to re-open, but because it's a browser-specific issue I've instead opened bug 65554 to get this fixed.",task_subcomment,"(In reply to Luis Villa (personal-for work use lvilla@wikimedia.org) from comment #11)
QUOTE
QUOTE

Was going to re-open, but because it's a browser-specific issue I've instead opened bug 65554 to get this fixed.",ACTION ON ISSUE
251348,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"This is broken (again?) The three license links come up before the action buttons (and save page never comes up, but that is bug 50047 I think?)",task_subcomment,"This is broken (again?) The three license links come up before the action buttons (and save page never comes up, but that is bug 50047 I think?)",BUG REPRODUCTION
251345,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,*** Bug 53257 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53257 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
251340,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.",task_subcomment,"The fix for this is now merged and will be deployed on Thursday 10 October to MediaWiki.org, and to Wikipedias on Thursday 17 October.",ACTION ON ISSUE
251335,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876",task_subcomment,"Change 81876 merged by jenkins-bot:
Make the save dialog an actual dialog

GERRIT_URL",SOLUTION USAGE
251331,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

https://gerrit.wikimedia.org/r/81876",task_subcomment,"Change 81876 had a related patch set uploaded by Jforrester:
Make the save dialog an actual dialog

GERRIT_URL",SOLUTION USAGE
251327,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,*** Bug 53257 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 53257 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
251322,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"Dcoetzee at en.wp reports that the tab order differs in different browsers, and that at a certain point in firefox the focus gets stuck and neither tab nor shift-tab can move it.

The full comment is below:
    ""On Chrome Version 28.0.1500.95 m on Windows 7 x64: It starts in the edit summary field, goes to the ""minor edit"" link (not the checkbox), then the Save page button, then the Review your changes button (moving right to left), then the three links in the small text at the bottom, then the address bar, then the Search box, then the minor edit checkbox, then the ""Interactions"" menu drop down on the left sidebar (???), then the Watch this page checkbox. If I use SHIFT+TAB it goes to Edit summary link, then jumps straight to the Mediawiki logo way in the bottom right.

    On Firefox 22.0 and 23.0 on Windows 7 x64: It starts in the edit summary field, goes to the ""minor edit"" link (not the checkbox), then the Save page button, then thereafter neither TAB nor SHIFT+TAB do anything (focus is stuck - this is a serious problem as it may require reloading the page and losing edits). SHIFT+TAB is same as in Chrome.

Conventionally, tab order is supposed to go in a logical reading order: left-to-right, top-to-bottom. My expected order was something like this:

    Starts in edit summary field, goes to minor edit checkbox, then minor edit link, then Watch this page checkbox, then Review your changes button, then Save page button, then the three links at the bottom. If I use SHIFT+TAB to tab backwards, I expect to visit the Edit summary link, then (if possible) the arrow to collapse/abort the Save, then the Search box.""",task_subcomment,"Dcoetzee at en.wp reports that the tab order differs in different browsers, and that at a certain point in firefox the focus gets stuck and neither tab nor shift-tab can move it.

The full comment is below:
    ""On Chrome Version 28.0.1500.95 m on Windows 7 x64: It starts in the edit summary field, goes to the ""minor edit"" link (not the checkbox), then the Save page button, then the Review your changes button (moving right to left), then the three links in the small text at the bottom, then the address bar, then the Search box, then the minor edit checkbox, then the ""Interactions"" menu drop down on the left sidebar (???), then the Watch this page checkbox. If I use SHIFT+TAB it goes to Edit summary link, then jumps straight to the Mediawiki logo way in the bottom right.

    On Firefox 22.0 and 23.0 on Windows 7 x64: It starts in the edit summary field, goes to the ""minor edit"" link (not the checkbox), then the Save page button, then thereafter neither TAB nor SHIFT+TAB do anything (focus is stuck - this is a serious problem as it may require reloading the page and losing edits). SHIFT+TAB is same as in Chrome.

Conventionally, tab order is supposed to go in a logical reading order: left-to-right, top-to-bottom. My expected order was something like this:

    Starts in edit summary field, goes to minor edit checkbox, then minor edit link, then Watch this page checkbox, then Review your changes button, then Save page button, then the three links at the bottom. If I use SHIFT+TAB to tab backwards, I expect to visit the Edit summary link, then (if possible) the arrow to collapse/abort the Save, then the Search box.""",OBSERVED BUG BEHAVIOR
251314,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"There has been a slight change to this recently but it is still wrong.

Current behaviour: Pressing tab from the summary box leads to the minor edit link
Desired behaviour: It should lead to the minor edit checkbox (not the link)",task_subcomment,"There has been a slight change to this recently but it is still wrong.

Current behaviour: Pressing tab from the summary box leads to the minor edit link
Desired behaviour: It should lead to the minor edit checkbox (not the link)",BUG REPRODUCTION
251308,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,*** Bug 52080 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52080 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
251300,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"That is an enhancement MZMcBride.

*** This bug has been marked as a duplicate of bug 50047 ***",task_subcomment,"That is an enhancement MZMcBride.

*** This bug has been marked as a duplicate of bug 50047 ***",ACTION ON ISSUE
251292,VisualEditor: Change tab order in save dialog to be more like the wikitext editor's save form,"Yeah, VisualEditor is kind of disruptive in this way. I'd like some further thought here.",task_subcomment,"Yeah, VisualEditor is kind of disruptive in this way. I'd like some further thought here.",SOLUTION DISCUSSION
53915,VisualEditor: Return of the invalid token on save attempt problem?,"(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",task_description,"(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 URL 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",BUG REPRODUCTION
251119,VisualEditor: Return of the invalid token on save attempt problem?,This was fixed in gerrit 76859 which was merged yesterday and will go out today.,task_subcomment,This was fixed in gerrit 76859 which was merged yesterday and will go out today.,SOLUTION USAGE
251112,VisualEditor: Return of the invalid token on save attempt problem?,"**mael.leguevel** wrote:

I had the same message with the following scenario:
Edit an article, not logged in. Then, log in from another tab. Trying to save the article from the first tab, I get the same error message.",task_subcomment,"**mael.leguevel** wrote:

I had the same message with the following scenario:
Edit an article, not logged in. Then, log in from another tab. Trying to save the article from the first tab, I get the same error message.",BUG REPRODUCTION
251105,VisualEditor: Return of the invalid token on save attempt problem?,"en.wp editor Rpyle731 has just reported an occurrence of this:
""While putting in stub templates in article ""[[Zhang Shi (prince)]]"" using the visual editor, when trying to save I got the text 

""Error loading data from server. Unsuccessful request: Invalid token.""""",task_subcomment,"en.wp editor Rpyle731 has just reported an occurrence of this:
""While putting in stub templates in article ""[[Zhang Shi (prince)]]"" using the visual editor, when trying to save I got the text 

""Error loading data from server. Unsuccessful request: Invalid token.""""",BUG REPRODUCTION
251098,VisualEditor: Return of the invalid token on save attempt problem?,"(In reply to comment #1)
FWIW when I investigated this by clicking the final [Save page] again, I only saw the one visualeditoredit API request in Firebug's Network tab.",task_subcomment,"(In reply to comment #1)
FWIW when I investigated this by clicking the final [Save page] again, I only saw the one visualeditoredit API request in Firebug's Network tab.",BUG REPRODUCTION
251091,VisualEditor: Return of the invalid token on save attempt problem?,"When the API responds with badtoken, VE *should* refetch the token and try again. I'm fairly sure that was implemented, but not 100% sure.",task_subcomment,"When the API responds with badtoken, VE *should* refetch the token and try again. I'm fairly sure that was implemented, but not 100% sure.",SOLUTION DISCUSSION
53902,VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog,"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",task_description,"If you look at page settings under URL 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",BUG REPRODUCTION
250163,VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog,Now fixed in master.,task_subcomment,Now fixed in master.,SOLUTION USAGE
250157,VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog,"Change 75859 merged by jenkins-bot:
Parse category names correctly

https://gerrit.wikimedia.org/r/75859",task_subcomment,"Change 75859 merged by jenkins-bot:
Parse category names correctly

GERRIT_URL",ACTION ON ISSUE
250151,VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog,"Change 75859 had a related patch set uploaded by Esanders:
Parse category names correctly

https://gerrit.wikimedia.org/r/75859",task_subcomment,"Change 75859 had a related patch set uploaded by Esanders:
Parse category names correctly

GERRIT_URL",ACTION ON ISSUE
250147,VisualEditor: Categories with colons in their name do not display properly in the meta-data dialog,"This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].",task_subcomment,"This style of category name also appears at de.wikipedia, e.g., [[:de:Kategorie:Wikipedia:Schnelllöschen]].",SOLUTION USAGE
53883,VisualEditor: Language templates replaced by snowmen at Japanese Wikipedia,"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",task_description,"The error can be seen at URL

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**: URL",BUG REPRODUCTION
249259,VisualEditor: Language templates replaced by snowmen at Japanese Wikipedia,I think that this was finally fixed in Roan's great re-working of snowmen.,task_subcomment,I think that this was finally fixed in Roan's great re-working of snowmen.,SOLUTION DISCUSSION
249255,VisualEditor: Language templates replaced by snowmen at Japanese Wikipedia,"I have just duplicated this in Thai wikipedia.  Not only does the {{lang-en}} template turn into snowmen, the surrounding text gets rendered into (bolded) English upon saving. 

Diff:https://th.wikipedia.org/w/index.php?title=%E0%B8%81%E0%B8%8E%E0%B8%AB%E0%B8%A1%E0%B8%B2%E0%B8%A2%E0%B8%9B%E0%B8%B4%E0%B8%94%E0%B8%9B%E0%B8%B2%E0%B8%81&diff=5062666&oldid=4871033

Chrome 28.0.1500.71, OS 10.6.8",task_subcomment,"I have just duplicated this in Thai wikipedia.  Not only does the {{lang-en}} template turn into snowmen, the surrounding text gets rendered into (bolded) English upon saving. 

Diff:URL

Chrome 28.0.1500.71, OS 10.6.8",BUG REPRODUCTION
249249,VisualEditor: Language templates replaced by snowmen at Japanese Wikipedia,"I quickly tried to reproduce this, and failed.  It might have been fixed by improvements to the code.  It would be good if someone can ask B637pcgt what they did to cause this issue.

jawp still has only a few VE edits per day
https://ja.wikipedia.org/wiki/special:recentchanges?tagfilter=visualeditor&days=30&limit=500",task_subcomment,"I quickly tried to reproduce this, and failed.  It might have been fixed by improvements to the code.  It would be good if someone can ask B637pcgt what they did to cause this issue.

jawp still has only a few VE edits per day
URL",BUG REPRODUCTION
53851,"VisualEditor: By default, images should not set the alignment","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",task_description,"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",BUG REPRODUCTION
247432,"VisualEditor: By default, images should not set the alignment","Change 75526 merged by jenkins-bot:
Image insertion alignment fix

https://gerrit.wikimedia.org/r/75526",task_subcomment,"Change 75526 merged by jenkins-bot:
Image insertion alignment fix

GERRIT_URL",ACTION ON ISSUE
247429,"VisualEditor: By default, images should not set the alignment","Change 75526 had a related patch set uploaded by Mooeypoo:
Image insertion alignment fix

https://gerrit.wikimedia.org/r/75526",task_subcomment,"Change 75526 had a related patch set uploaded by Mooeypoo:
Image insertion alignment fix

GERRIT_URL",SOLUTION USAGE
247426,"VisualEditor: By default, images should not set the alignment",*** Bug 51295 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51295 has been marked as a duplicate of this bug. ***,ACTION ON ISSUE
247423,"VisualEditor: By default, images should not set the alignment","Unless I'm missing something, just remove if it's the default anyway. See an example:
https://en.wikipedia.org/wiki/User:Amire80/ve_default_image_alignment",task_subcomment,"Unless I'm missing something, just remove if it's the default anyway. See an example:
URL",SOLUTION DISCUSSION
247417,"VisualEditor: By default, images should not set the alignment",Should we remove the alignment completely (and risk people not putting one in? what's the potential side-effect of that?) or change the 'right' to 'left' on RTL wikis?,task_subcomment,Should we remove the alignment completely (and risk people not putting one in? what's the potential side-effect of that?) or change the 'right' to 'left' on RTL wikis?,SOLUTION DISCUSSION
53828,VisualEditor: Autocompletion for template names doesn't work in RTL,"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",task_description,"Given that I'm editing an article in an RTL wiki: URL
   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",BUG REPRODUCTION
246135,VisualEditor: Autocompletion for template names doesn't work in RTL,"Done and will be deployed tomorrow. Thanks, Moriel!",task_subcomment,"Done and will be deployed tomorrow. Thanks, Moriel!",SOLUTION USAGE
246130,VisualEditor: Autocompletion for template names doesn't work in RTL,"This bug will be fixed with this patchset: https://gerrit.wikimedia.org/r/#/c/74835/

See also https://bugzilla.wikimedia.org/show_bug.cgi?id=51490",task_subcomment,"This bug will be fixed with this patchset: URL

See also URL",SOLUTION USAGE
53819,VisualEditor: Location of the inspector menu is wrong for floated content in RTL wikis,"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}",task_description,"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:
URL

See also the screenshot.

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11560}",BUG REPRODUCTION
245647,VisualEditor: Location of the inspector menu is wrong for floated content in RTL wikis,Merged and will go out tomorrow.,task_subcomment,Merged and will go out tomorrow.,SOLUTION USAGE
245641,VisualEditor: Location of the inspector menu is wrong for floated content in RTL wikis,"Change 75246 merged by jenkins-bot:
Quickfix for Transclusion icon in RTL wikis

https://gerrit.wikimedia.org/r/75246",task_subcomment,"Change 75246 merged by jenkins-bot:
Quickfix for Transclusion icon in RTL wikis

GERRIT_URL",ACTION ON ISSUE
245636,VisualEditor: Location of the inspector menu is wrong for floated content in RTL wikis,"Change 75246 had a related patch set uploaded by Mooeypoo:
Quickfix for Transclusion icon in RTL wikis

https://gerrit.wikimedia.org/r/75246",task_subcomment,"Change 75246 had a related patch set uploaded by Mooeypoo:
Quickfix for Transclusion icon in RTL wikis

GERRIT_URL",SOLUTION USAGE
53739,VisualEditor: [Regression] Dialog panels not scrollable,"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",task_description,"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: URL

--------------------------
**Version**: unspecified
**Severity**: major
**See Also**:
URL",BUG REPRODUCTION
240973,VisualEditor: [Regression] Dialog panels not scrollable,Done and will be deployed tomorrow.,task_subcomment,Done and will be deployed tomorrow.,SOLUTION USAGE
240969,VisualEditor: [Regression] Dialog panels not scrollable,"Change 74836 merged by jenkins-bot:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

https://gerrit.wikimedia.org/r/74836",task_subcomment,"Change 74836 merged by jenkins-bot:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

GERRIT_URL",ACTION ON ISSUE
240964,VisualEditor: [Regression] Dialog panels not scrollable,*** Bug 51810 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51810 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
240959,VisualEditor: [Regression] Dialog panels not scrollable,Patch by Rillke from bug 51793: https://gerrit.wikimedia.org/r/75083,task_subcomment,Patch by Rillke from bug 51793: GERRIT_URL,BUG REPRODUCTION
240955,VisualEditor: [Regression] Dialog panels not scrollable,*** Bug 51793 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51793 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
240947,VisualEditor: [Regression] Dialog panels not scrollable,*** Bug 51671 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51671 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
240939,VisualEditor: [Regression] Dialog panels not scrollable,"Change 74836 had a related patch set uploaded by Matmarex:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

https://gerrit.wikimedia.org/r/74836",task_subcomment,"Change 74836 had a related patch set uploaded by Matmarex:
Ensure ve-ui-panelLayout-scrollable is actually scrollable

GERRIT_URL",TASK PROGRESS
240931,VisualEditor: [Regression] Dialog panels not scrollable,Caused by 8409d16f0f2392cea321aa3d8d6bc692f3f04f27,task_subcomment,Caused by 8409d16f0f2392cea321aa3d8d6bc692f3f04f27,BUG REPRODUCTION
53734,TemplateData: Create an editor for template data (in the wikitext editor),"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}",task_description,"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 :
* URL
* URL

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
URL

**Attached**: {F11375}",SOLUTION DISCUSSION
240753,TemplateData: Create an editor for template data (in the wikitext editor),Follow-up in 60158.,task_subcomment,Follow-up in 60158.,ACTION ON ISSUE
240749,TemplateData: Create an editor for template data (in the wikitext editor),"Created attachment 14428
TemplateDataGenertor screenshot

I made a screenshot. I’ve cropped it to show only TemplateDataGenerator: it is a jQuery UI dialog centered on the screen.

**Attached**: {F11377}",task_subcomment,"Created attachment 14428
TemplateDataGenertor screenshot

I made a screenshot. I’ve cropped it to show only TemplateDataGenerator: it is a jQuery UI dialog centered on the screen.

**Attached**: {F11377}",SOLUTION USAGE
240739,TemplateData: Create an editor for template data (in the wikitext editor),"As I said, the current information (or lack of) is confusing. Is there any wiki page or screenshot or anything we can link to?

In any case, ca.wiki wants to try it.  :)",task_subcomment,"As I said, the current information (or lack of) is confusing. Is there any wiki page or screenshot or anything we can link to?

In any case, ca.wiki wants to try it.  :)",SOLUTION USAGE
240733,TemplateData: Create an editor for template data (in the wikitext editor),"$wgTemplateDataUseGUI activates neither TemplateDataEditor nor TDSkell but TemplateDataGenerator. The two screenshots attached to this bug are for 'TemplateDataEditor' and 'TemplateData Editor', so the one you gave on cawiki is not correct.",task_subcomment,"$wgTemplateDataUseGUI activates neither TemplateDataEditor nor TDSkell but TemplateDataGenerator. The two screenshots attached to this bug are for 'TemplateDataEditor' and 'TemplateData Editor', so the one you gave on cawiki is not correct.",BUG REPRODUCTION
240726,TemplateData: Create an editor for template data (in the wikitext editor),"ca.wiki is also happy to test it, see https://ca.wikipedia.org/wiki/Viquip%C3%A8dia:La_taverna/Propostes#Activar_TemplateDataEditor",task_subcomment,"ca.wiki is also happy to test it, see URL",SOLUTION USAGE
240718,TemplateData: Create an editor for template data (in the wikitext editor),"**M8R-0p6s0d** wrote:

Hi, we would like to try the TempalteDataEditor on NL wiki, see https://nl.wikipedia.org/wiki/Wikipedia:De_kroeg#Aanzetten_TemplateData-editor_op_nl-wiki",task_subcomment,"**M8R-0p6s0d** wrote:

Hi, we would like to try the TempalteDataEditor on NL wiki, see URL",POTENTIAL NEW ISSUES AND REQUESTS
240712,TemplateData: Create an editor for template data (in the wikitext editor),"No, this is the GUI we developed hidden behind $wgTemplateDataUseGUI.",task_subcomment,"No, this is the GUI we developed hidden behind $wgTemplateDataUseGUI.",SOLUTION DISCUSSION
240705,TemplateData: Create an editor for template data (in the wikitext editor),"(In reply to comment #11)
> If
> a particular wiki is happy to be a guinea pig we can switch it on there for a
> little for some real-world testing.

Sound interesting, but I'm missing a bit of background...

Do you mean ""switch on"" https://en.wikipedia.org/wiki/User:Salix_alba/TDSkell ? Would it be enabled to all users of a wiki or can it be restricted to a certain user group in order limit the experiment a bit?

There is clear interest in improving template data coverage in Catalan Wikipedia but, guess what, nobody really enjoys editing JSON syntax.  :)",task_subcomment,"(In reply to comment #11)
QUOTE
QUOTE
QUOTE

Sound interesting, but I'm missing a bit of background...

Do you mean ""switch on"" URL ? Would it be enabled to all users of a wiki or can it be restricted to a certain user group in order limit the experiment a bit?

There is clear interest in improving template data coverage in Catalan Wikipedia but, guess what, nobody really enjoys editing JSON syntax.  :)",SOLUTION DISCUSSION
240697,TemplateData: Create an editor for template data (in the wikitext editor),"This is done in I863a8199c0b08cc52b320ed00dcba912dd2aeefc (though it's not yet deployed, as it is currently hidden behind a feature flag). Closing for now. If a particular wiki is happy to be a guinea pig we can switch it on there for a little for some real-world testing.",task_subcomment,"This is done in I863a8199c0b08cc52b320ed00dcba912dd2aeefc (though it's not yet deployed, as it is currently hidden behind a feature flag). Closing for now. If a particular wiki is happy to be a guinea pig we can switch it on there for a little for some real-world testing.",ACTION ON ISSUE
240691,TemplateData: Create an editor for template data (in the wikitext editor),"Change 85400 had a related patch set uploaded by Jforrester:
TemplateData Generator GUI

https://gerrit.wikimedia.org/r/85400",task_subcomment,"Change 85400 had a related patch set uploaded by Jforrester:
TemplateData Generator GUI

GERRIT_URL",ACTION ON ISSUE
240683,TemplateData: Create an editor for template data (in the wikitext editor),"Skeleton generator now in javascript and at http://en.wikipedia.org/wiki/User:Salix_alba/TDSkell
its quite handy for getting a complete list of parameters. The human written documentation is not always upto date.",task_subcomment,"Skeleton generator now in javascript and at URL
its quite handy for getting a complete list of parameters. The human written documentation is not always upto date.",SOLUTION USAGE
240675,TemplateData: Create an editor for template data (in the wikitext editor),"I don't know how I messed up with the bug number (probably several bugzilla windows opened and I paste the wrong one) ;-) Sorry, bug 50169 of course.

I also think having a button in the toolbar would be a better place than the sidebar.


Other possible optimization: combine it with the ""Skeleton generator"" so that parameter names are automatically retrieved from the template source code for initializing the templatedata the first time. Care must be taken since the templatedata will often be on the documentation page.

http://singsurf.org/things/TemplateData.php?Source=true",task_subcomment,"I don't know how I messed up with the bug number (probably several bugzilla windows opened and I paste the wrong one) ;-) Sorry, bug 50169 of course.

I also think having a button in the toolbar would be a better place than the sidebar.


Other possible optimization: combine it with the ""Skeleton generator"" so that parameter names are automatically retrieved from the template source code for initializing the templatedata the first time. Care must be taken since the templatedata will often be on the documentation page.

URL",SOLUTION DISCUSSION
240667,TemplateData: Create an editor for template data (in the wikitext editor),"(In reply to comment #0)
> Created attachment 12900 [details]
> GUI for the existing TemplateDataEditor
> 
> Not the same as bug 50964

Indeed, bug 50964 is not the same, but also (apparently) completely unrelated. I assume you meant bug 50169.

If this should not (also) be inside VisualEditor, can we be specific in what we want it to be then?

e.g. WikiEditor, legacy toolbar, ...

The referenced gadget 'parses' the wikitext textarea and adds a link in the sidebar toolbox that opens a dialog. I don't think the sidebar would be an acceptable entry point to edit the wikitext. Should be something in the toolbar.

I agree we should re-use the data logic between these 2 or 3 different things. At least we can expose the data logic separately from the plugin we make for VisualEditor so that other ones can be created as gadget (until (if) we make one of the WikiEditor and/or legacy toolbar).

**Attached**: {F11375}",task_subcomment,"(In reply to comment #0)
QUOTE
QUOTE
QUOTE
QUOTE

Indeed, bug 50964 is not the same, but also (apparently) completely unrelated. I assume you meant bug 50169.

If this should not (also) be inside VisualEditor, can we be specific in what we want it to be then?

e.g. WikiEditor, legacy toolbar, ...

The referenced gadget 'parses' the wikitext textarea and adds a link in the sidebar toolbox that opens a dialog. I don't think the sidebar would be an acceptable entry point to edit the wikitext. Should be something in the toolbar.

I agree we should re-use the data logic between these 2 or 3 different things. At least we can expose the data logic separately from the plugin we make for VisualEditor so that other ones can be created as gadget (until (if) we make one of the WikiEditor and/or legacy toolbar).

**Attached**: {F11375}",SOLUTION DISCUSSION
240661,TemplateData: Create an editor for template data (in the wikitext editor),"Created attachment 12957
Screenshot of http://tools.wikimedia.pl/~mlazowik/templatedata/

**Attached**: {F11376}",task_subcomment,"Created attachment 12957
Screenshot of URL

**Attached**: {F11376}",ATTACHMENT
240656,TemplateData: Create an editor for template data (in the wikitext editor),"This is, indeed, not a duplicate of bug 50169, though it might as well be done in one go. Relabelling as such.",task_subcomment,"This is, indeed, not a duplicate of bug 50169, though it might as well be done in one go. Relabelling as such.",ACTION ON ISSUE
240654,TemplateData: Create an editor for template data (in the wikitext editor),"(In reply to comment #1)
> Could you please define what that ""tool"" would exactly do? 
> Otherwise it will be extremely hard to define when this bug report could be
> considered ""fixed"" at some point. :)

Being able to edit a  tag in a user frienly way, much like what TemplateDataEditor allows (see the attached screenshot in my first comment). JSON is not very friendly for human editors.
Basically, a window showing all the informations in the  and allowing a human editor to modify them easily.

Extra advantage of including this in the TemplateData extension :
* Users don't have to modify their common.js to have access to an editor",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE
QUOTE

Being able to edit a  tag in a user frienly way, much like what TemplateDataEditor allows (see the attached screenshot in my first comment). JSON is not very friendly for human editors.
Basically, a window showing all the informations in the  and allowing a human editor to modify them easily.

Extra advantage of including this in the TemplateData extension :
* Users don't have to modify their common.js to have access to an editor",MOTIVATION
240649,TemplateData: Create an editor for template data (in the wikitext editor),"(In reply to comment #0)
...
> editing TemplateData also outside VisualEditor (I even think it's better than
> inside VisualEditor because VE doesn't work on Template namespace right now).

BTW: depending on the resolution of bug 50512, the data might be migrated from Template namespace to a specific one.",task_subcomment,"(In reply to comment #0)
...
QUOTE
QUOTE

BTW: depending on the resolution of bug 50512, the data might be migrated from Template namespace to a specific one.",SOLUTION DISCUSSION
240644,TemplateData: Create an editor for template data (in the wikitext editor),Tool = something at least as good as the TemplateDataEditor linked above.,task_subcomment,Tool = something at least as good as the TemplateDataEditor linked above.,SOLUTION DISCUSSION
240640,TemplateData: Create an editor for template data (in the wikitext editor),"Could you please define what that ""tool"" would exactly do? 
Otherwise it will be extremely hard to define when this bug report could be considered ""fixed"" at some point. :)",task_subcomment,"Could you please define what that ""tool"" would exactly do? 
Otherwise it will be extremely hard to define when this bug report could be considered ""fixed"" at some point. :)",TASK PROGRESS
53708,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items","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
    1"" wraps correctly

""Long text
1""
""Long text
    "" and
""Long text
    
"" 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",task_description,"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
    1"" wraps correctly

""Long text
1""
""Long text
    "" and
""Long text
    
"" all exhibit this bug.

--------------------------
**Version**: unspecified
**Severity**: normal
**See Also**:
URL
URL",BUG REPRODUCTION
239329,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items","Change 139806 merged by jenkins-bot:
Remove display:inline-block highlight hacks

https://gerrit.wikimedia.org/r/139806",task_subcomment,"Change 139806 merged by jenkins-bot:
Remove display:inline-block highlight hacks

GERRIT_URL",ACTION ON ISSUE
239325,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items","Change 139806 had a related patch set uploaded by Esanders:
Remove display:inline-block highlight hacks

https://gerrit.wikimedia.org/r/139806",task_subcomment,"Change 139806 had a related patch set uploaded by Esanders:
Remove display:inline-block highlight hacks

GERRIT_URL",ACTION ON ISSUE
239319,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items","Inline templates are overridden to inline-block, but setting them back to inline would mean we have to calculate the highlights using getClientRects. Might want to wait for the much discussed SVG highlights for this?",task_subcomment,"Inline templates are overridden to inline-block, but setting them back to inline would mean we have to calculate the highlights using getClientRects. Might want to wait for the much discussed SVG highlights for this?",SOLUTION DISCUSSION
239313,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items",*** Bug 62800 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 62800 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
239306,"VisualEditor: Inline templates don't wrap, assume width:100%, so break layout around floated items",*** Bug 52320 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52320 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
53679,VisualEditor: unlinking via linking tool triggers weird behaviors,"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",task_description,"See URL .

URL

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",BUG REPRODUCTION
237554,VisualEditor: unlinking via linking tool triggers weird behaviors,"Worksforus, at it.wp. Will re-open if necessary.",task_subcomment,"Worksforus, at it.wp. Will re-open if necessary.",SOLUTION USAGE
237551,VisualEditor: unlinking via linking tool triggers weird behaviors,"Switching to Unconfirmed, since I can no longer reproduce this. Will ask other Italian testers if they can, otherwise I'll mark it as Resolved.",task_subcomment,"Switching to Unconfirmed, since I can no longer reproduce this. Will ask other Italian testers if they can, otherwise I'll mark it as Resolved.",TASK PROGRESS
237548,VisualEditor: unlinking via linking tool triggers weird behaviors,"Another user reports getting the weird cursor but being still able to work regularly after that (his specs, Firefox on W7 64bit, Monobook).
I'm looking for the quickest way to produce screencasts for you (Chrome does not seem to have valid plugins for that unfortunately).",task_subcomment,"Another user reports getting the weird cursor but being still able to work regularly after that (his specs, Firefox on W7 64bit, Monobook).
I'm looking for the quickest way to produce screencasts for you (Chrome does not seem to have valid plugins for that unfortunately).",SOLUTION USAGE
237545,VisualEditor: unlinking via linking tool triggers weird behaviors,"Don't even mention it, James :)
Sorry I can't provide a video today ;)
but will try to explain more carefully.
It definitely still occurs, it was just reported (among other things) in

http://it.wikipedia.org/wiki/Rodney .

The clear formatting works fine.
Properly unlinking a single word works fine.
In this article, if I just select, say, from ""toponimo"" to ""antica"" and use the linking tool to unlink, I will be able to do it the first time but then I'll get the limited functionalities listed above.
The same if I just select ""adespota,"" .
I don't do anything else before or after that.
It happens with both Monobook and Vector and on en.wp as well, I just tried editing the article ""Penguin"".

Thanks.",task_subcomment,"Don't even mention it, James :)
Sorry I can't provide a video today ;)
but will try to explain more carefully.
It definitely still occurs, it was just reported (among other things) in

URL .

The clear formatting works fine.
Properly unlinking a single word works fine.
In this article, if I just select, say, from ""toponimo"" to ""antica"" and use the linking tool to unlink, I will be able to do it the first time but then I'll get the limited functionalities listed above.
The same if I just select ""adespota,"" .
I don't do anything else before or after that.
It happens with both Monobook and Vector and on en.wp as well, I just tried editing the article ""Penguin"".

Thanks.",BUG REPRODUCTION
237542,VisualEditor: unlinking via linking tool triggers weird behaviors,"I can't reproduce this in either Chrome or Firefox - by drag-selecting the word with the mouse, right-clicking, double-clicking; and by selection with the keyboard or drag-clicking with the mouse to select more than the word, using both the link inspector and its remove (""trash"") icon and the general ""clear formatting"" tool. :-(

Does this occur on every page? What about after a hard-refresh? Can you make a video/screencast of you doing this so I can see exactly how it occurs? Sorry to ask so much!",task_subcomment,"I can't reproduce this in either Chrome or Firefox - by drag-selecting the word with the mouse, right-clicking, double-clicking; and by selection with the keyboard or drag-clicking with the mouse to select more than the word, using both the link inspector and its remove (""trash"") icon and the general ""clear formatting"" tool. :-(

Does this occur on every page? What about after a hard-refresh? Can you make a video/screencast of you doing this so I can see exactly how it occurs? Sorry to ask so much!",BUG REPRODUCTION
53670,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"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}",task_description,"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**:
URL

**Attached**: {F11265}",BUG REPRODUCTION
237017,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"Will this allow searching on instring matches of both title and label? 

If not, will that be covered by bug 51822 or is a new bug required?",task_subcomment,"Will this allow searching on instring matches of both title and label? 

If not, will that be covered by bug 51822 or is a new bug required?",SOLUTION DISCUSSION
237013,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September, and to Wikipedias on Thursday 12 September. Sorry for the disruption.",task_subcomment,"This is now fixed in master, and will be released to MediaWiki.org on Thursday 5 September, and to Wikipedias on Thursday 12 September. Sorry for the disruption.",SOLUTION USAGE
237007,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"Change 82055 merged by jenkins-bot:
Include param label in search index

https://gerrit.wikimedia.org/r/82055",task_subcomment,"Change 82055 merged by jenkins-bot:
Include param label in search index

GERRIT_URL",ACTION ON ISSUE
237002,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"Change 82055 had a related patch set uploaded by Trevor Parscal:
Include param label in search index

https://gerrit.wikimedia.org/r/82055",task_subcomment,"Change 82055 had a related patch set uploaded by Trevor Parscal:
Include param label in search index

GERRIT_URL",ACTION ON ISSUE
236994,VisualEditor: Transclusion dialog parameter filter should search on both parameter name and parameter label,"A user on Wikipedia has determined that the cause is that the data the search function searches on is the internal parameter name, which is invisible to the user, not the visible label. This is very wrong. 

""So VE users have learned that the only way, in the Transclusion/Template dialog, to add a parameter is to type the parameter name, then press Enter. But that just changed - now you click the parameter name to select it. That's more obvious - but if, for some reason, having learned the old way, you continue to use it - that's trouble.

Example: Cite web. Let's suppose I want to add the parameter ""Month of publication"". I type that, hit Enter, and there it is, on the left. Except, not really. VE thinks this is a parameter not on its list - you can tell that because there is no description just above the input box where you enter the value of that parameter. (Compare to entering a value for the parameter ""Source title"").

Under the hood, here's what happens: VE knows that ""Source title"" is the label (via TemplateData) for the parameter ""title"". (Similarly, ""URL"" is the label for the parameter ""url"" - and yes, parameters are case sensitive.) But VE doesn't know that ""Month of publication"" (typed) is the label for the parameter ""month"". So the template code that VE actually stores is this:

    {{Cite web|url = http://example.com|title = Whatever the title is|Month of publication = June}}

That doesn't cause a visible problem on the VE edit page. However, in this case, after saving the page, what is displayed to readers is ""Unknown parameter |Month of publication= ignored (help) ""

Recommendation: If a person types the name of a parameter and presses Enter, VE should check the typed name against the list of labels in TemplateData, for that template, and if there is a match, handle the new parameter just as if the person had clicked the matching parameter rather than typed it.""",task_subcomment,"A user on Wikipedia has determined that the cause is that the data the search function searches on is the internal parameter name, which is invisible to the user, not the visible label. This is very wrong. 

""So VE users have learned that the only way, in the Transclusion/Template dialog, to add a parameter is to type the parameter name, then press Enter. But that just changed - now you click the parameter name to select it. That's more obvious - but if, for some reason, having learned the old way, you continue to use it - that's trouble.

Example: Cite web. Let's suppose I want to add the parameter ""Month of publication"". I type that, hit Enter, and there it is, on the left. Except, not really. VE thinks this is a parameter not on its list - you can tell that because there is no description just above the input box where you enter the value of that parameter. (Compare to entering a value for the parameter ""Source title"").

Under the hood, here's what happens: VE knows that ""Source title"" is the label (via TemplateData) for the parameter ""title"". (Similarly, ""URL"" is the label for the parameter ""url"" - and yes, parameters are case sensitive.) But VE doesn't know that ""Month of publication"" (typed) is the label for the parameter ""month"". So the template code that VE actually stores is this:

    {{Cite web|url = URL = Whatever the title is|Month of publication = June}}

That doesn't cause a visible problem on the VE edit page. However, in this case, after saving the page, what is displayed to readers is ""Unknown parameter |Month of publication= ignored (help) ""

Recommendation: If a person types the name of a parameter and presses Enter, VE should check the typed name against the list of labels in TemplateData, for that template, and if there is a match, handle the new parameter just as if the person had clicked the matching parameter rather than typed it.""",INVESTIGATION AND EXPLORATION
53636,VisualEditor: Saving fails silently when the database is locked,"**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}",task_description,"**Author:** CODE

**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**:
URL

**Attached**: {F11178}",BUG REPRODUCTION
235136,VisualEditor: Saving fails silently when the database is locked,Fixed and will get deployed in a few minutes' time.,task_subcomment,Fixed and will get deployed in a few minutes' time.,SOLUTION USAGE
235128,VisualEditor: Saving fails silently when the database is locked,"Change 75561 merged by jenkins-bot:
Show error when trying to save in read-only mode

https://gerrit.wikimedia.org/r/75561",task_subcomment,"Change 75561 merged by jenkins-bot:
Show error when trying to save in read-only mode

GERRIT_URL",ACTION ON ISSUE
235121,VisualEditor: Saving fails silently when the database is locked,"Change 75561 had a related patch set uploaded by Esanders:
Show when trying to save in read-only mode

https://gerrit.wikimedia.org/r/75561",task_subcomment,"Change 75561 had a related patch set uploaded by Esanders:
Show when trying to save in read-only mode

GERRIT_URL",TASK PROGRESS
235115,VisualEditor: Saving fails silently when the database is locked,"Two other users have reported the same thing on en.wikipedia, so the cause was the database being locked.

Could be related to Bug 50472 which is marked as fixed but has apparently not yet been deployed?",task_subcomment,"Two other users have reported the same thing on en.wikipedia, so the cause was the database being locked.

Could be related to Bug 50472 which is marked as fixed but has apparently not yet been deployed?",BUG REPRODUCTION
235109,VisualEditor: Saving fails silently when the database is locked,"**kwang** wrote:

error while editing source code.

**Attached**: {F11179}",task_subcomment,"**kwang** wrote:

error while editing source code.

**Attached**: {F11179}",BUG REPRODUCTION
235103,VisualEditor: Saving fails silently when the database is locked,"**kwang** wrote:

More details: when I edited the source it said that the database was locked. This is likely the issue that was happening, but the error wasn't showing up in the visual editor.",task_subcomment,"**kwang** wrote:

More details: when I edited the source it said that the database was locked. This is likely the issue that was happening, but the error wasn't showing up in the visual editor.",BUG REPRODUCTION
53596,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,"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",task_description,"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",BUG REPRODUCTION
233027,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

GERRIT_URL",ACTION ON ISSUE
233021,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,"Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

GERRIT_URL",ACTION ON ISSUE
233015,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.,task_subcomment,There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.,SOLUTION DISCUSSION
233007,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,"There's code to address this bug in the following patch, which is due to go live on mediawiki.org by 13 September 2013:

https://gerrit.wikimedia.org/r/#/c/82858/

It does not fix this completely, but it does make it possible to cursor left through the cluster with repeated consecutive keypresses.",task_subcomment,"There's code to address this bug in the following patch, which is due to go live on mediawiki.org by 13 September 2013:

URL

It does not fix this completely, but it does make it possible to cursor left through the cluster with repeated consecutive keypresses.",SOLUTION DISCUSSION
233001,VisualEditor: Cannot move cursor backwards on ligature cluster on Chrome,"Debug Information:

Grapheme breaks as per unicodejs:
0: ""സ""
1: ""ന്""
2: ""തോ""
3: ""ഷ്""

Ligature break 1 and 2 logically wrong because they form a single cluster ന്തോ. You cannot place a cursor in between this cluster. It is a single syllable too. Firefox allows you to place the cursor at all of these breaks anyway. Infact Firefox allows you to place the cursor even inside ligature programatically. Chrome allows cursor positioning only at logical positions.

In this specific case. VE is asking Chrome to place the cursor at end of  grapheme break #1(ന്). but Chrome does not obey it and place it at the end of #2 (തോ). This repeats in every left cursor movement and it looks like cursor is stuck at the end of തോ.

In my quick observation those logical positions does not match with the grapheme cluster boundary specification of Unicode (www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries).

That causes lot of inconstancy in the offset known to the data model of VE and the actual offset appearing in browser. It will lead to many unexpected behavior of cursor positioning and text selections.",task_subcomment,"Debug Information:

Grapheme breaks as per unicodejs:
0: ""സ""
1: ""ന്""
2: ""തോ""
3: ""ഷ്""

Ligature break 1 and 2 logically wrong because they form a single cluster ന്തോ. You cannot place a cursor in between this cluster. It is a single syllable too. Firefox allows you to place the cursor at all of these breaks anyway. Infact Firefox allows you to place the cursor even inside ligature programatically. Chrome allows cursor positioning only at logical positions.

In this specific case. VE is asking Chrome to place the cursor at end of  grapheme break #1(ന്). but Chrome does not obey it and place it at the end of #2 (തോ). This repeats in every left cursor movement and it looks like cursor is stuck at the end of തോ.

In my quick observation those logical positions does not match with the grapheme cluster boundary specification of Unicode (www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries).

That causes lot of inconstancy in the offset known to the data model of VE and the actual offset appearing in browser. It will lead to many unexpected behavior of cursor positioning and text selections.",BUG REPRODUCTION
53569,Reduce number of load.php calls on VisualEditor open (down from 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.",task_description,"On a regular page load:

* URL
* 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.",BUG REPRODUCTION
427961,Reduce number of load.php calls on VisualEditor open (down from 3),"Change 197402 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/197402]]",task_subcomment,"Change 197402 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[GERRIT_URL]]",TASK PROGRESS
427918,Reduce number of load.php calls on VisualEditor open (down from 3),"Change 197402 had a related patch set uploaded (by Jforrester):
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/197402]]
",task_subcomment,"Change 197402 had a related patch set uploaded (by Jforrester):
Load RL modules in one load.php request, rather than in two stages

[[GERRIT_URL]]
",TASK PROGRESS
426507,Reduce number of load.php calls on VisualEditor open (down from 3),"Change 193026 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[https://gerrit.wikimedia.org/r/193026]]",task_subcomment,"Change 193026 merged by jenkins-bot:
Load RL modules in one load.php request, rather than in two stages

[[GERRIT_URL]]",TASK PROGRESS
449826,Reduce number of load.php calls on VisualEditor open (down from 3),"Saves 1 request and 3KB.

From 20 total request (521KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).",task_subcomment,"Saves 1 request and 3KB.

From 20 total request (521KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).",SOLUTION USAGE
426504,Reduce number of load.php calls on VisualEditor open (down from 3),"Saves 1 request and 3KB.

From 20 total request (512KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).",task_subcomment,"Saves 1 request and 3KB.

From 20 total request (512KB), to 19 total requests (518KB).

Tested on localhost. (Page view + load editor; includes two EventLogging requests and some images).",SOLUTION USAGE
419493,Reduce number of load.php calls on VisualEditor open (down from 3),"Change 193026 had a related patch set uploaded (by Jforrester):
[WIP] Factor out loading code into TargetLoader

[[https://gerrit.wikimedia.org/r/193026]]
",task_subcomment,"Change 193026 had a related patch set uploaded (by Jforrester):
[WIP] Factor out loading code into TargetLoader

[[GERRIT_URL]]
",ACTION ON ISSUE
53538,VisualEditor: Reverse selections break copy paste functionality,"* 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",task_description,"* 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",BUG REPRODUCTION
254160,VisualEditor: Reverse selections break copy paste functionality,Now merged; will go out with next push.,task_subcomment,Now merged; will go out with next push.,SOLUTION USAGE
254154,VisualEditor: Reverse selections break copy paste functionality,"Change 80299 merged by jenkins-bot:
Fix copy and paste of backwards selction

https://gerrit.wikimedia.org/r/80299",task_subcomment,"Change 80299 merged by jenkins-bot:
Fix copy and paste of backwards selction

GERRIT_URL",ACTION ON ISSUE
254147,VisualEditor: Reverse selections break copy paste functionality,"Change 80299 had a related patch set uploaded by Esanders:
Fix copy and paste of backwards selction

https://gerrit.wikimedia.org/r/80299",task_subcomment,"Change 80299 had a related patch set uploaded by Esanders:
Fix copy and paste of backwards selction

GERRIT_URL",TASK PROGRESS
254140,VisualEditor: Reverse selections break copy paste functionality,I can confirm this is still happening in Firefox 23/linux,task_subcomment,I can confirm this is still happening in Firefox 23/linux,BUG REPRODUCTION
53532,VisualEditor: CTRL+Z occasionally inserts a pawn,"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",task_description,"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**:
URL
URL",BUG REPRODUCTION
253776,VisualEditor: CTRL+Z occasionally inserts a pawn,I believe these issues are now fixed.,task_subcomment,I believe these issues are now fixed.,SOLUTION USAGE
253769,VisualEditor: CTRL+Z occasionally inserts a pawn,"This is still happening occasionally, and almost always associated with undoing text added to a link. However I can't reproduce it every time.",task_subcomment,"This is still happening occasionally, and almost always associated with undoing text added to a link. However I can't reproduce it every time.",BUG REPRODUCTION
253762,VisualEditor: CTRL+Z occasionally inserts a pawn,en.wp thread for reference https://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=564648446#Adding_text_after_a_link_includes_that_text_in_the_link._Undoing_sometimes_gives_a_pawn,task_subcomment,en.wp thread for reference URL,TASK PROGRESS
53526,"VisualEditor: Fix ""Uncaught Error: Offset could not be translated to a DOM element and offset: 2409""","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}",task_description,"Screenshot of problem

1. Open URL
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


QUOTE
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}",BUG REPRODUCTION
574335,"VisualEditor: Fix ""Uncaught Error: Offset could not be translated to a DOM element and offset: 2409""","I just got that same error (""Uncaught Error: Offset could not be translated to a DOM element and offset: 458"") on Meta. Sadly, I don't know what caused it.",task_subcomment,"I just got that same error (""Uncaught Error: Offset could not be translated to a DOM element and offset: 458"") on Meta. Sadly, I don't know what caused it.",BUG REPRODUCTION
253489,"VisualEditor: Fix ""Uncaught Error: Offset could not be translated to a DOM element and offset: 2409""","This appears to now be fixed. Marking as such, though can't determine exactly what fixed fixed it (probably Ed's cursoring changes?).",task_subcomment,"This appears to now be fixed. Marking as such, though can't determine exactly what fixed fixed it (probably Ed's cursoring changes?).",SOLUTION USAGE
253483,"VisualEditor: Fix ""Uncaught Error: Offset could not be translated to a DOM element and offset: 2409""",Confirmed still happening.,task_subcomment,Confirmed still happening.,BUG REPRODUCTION
53525,VisualEditor: Block slug deletion causing very odd corruption/skipping/repeat/pawns,"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",task_description,"When doing the steps outlined below, strange '9' character plus a newline appears and input it jumped backwards after 3 character.

See URL for how it looks; Using URL as test ground.

1. Place marker under ""References"" header
2. hit ""backspace""
3. type ""foobar""

--------------------------
**Version**: unspecified
**Severity**: major
**URL**: URL",BUG REPRODUCTION
253442,VisualEditor: Block slug deletion causing very odd corruption/skipping/repeat/pawns,"Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",task_subcomment,"Resetting to FIXED; this was a confirmed broken behaviour which has subsequently been FIXED, as far as we can tell - probably by the re-write of the Content Editable surface interaction model.",EXPECTED BEHAVIOR
253436,VisualEditor: Block slug deletion causing very odd corruption/skipping/repeat/pawns,"(In reply to comment #2)
> Cannot reproduce it now on betalabs.

Where ""on betalabs""? Tested how exactly (which browsers and versions)? Current steps aren't transparent so somebody else couldn't recreate your conditions...

> It might got fixed.

""Might"" = no identifiable code commit = WORKSFORME instead of FIXED. See https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle",task_subcomment,"(In reply to comment #2)
QUOTE

Where ""on betalabs""? Tested how exactly (which browsers and versions)? Current steps aren't transparent so somebody else couldn't recreate your conditions...

QUOTE

""Might"" = no identifiable code commit = WORKSFORME instead of FIXED. See URL",ACTION ON ISSUE
253430,VisualEditor: Block slug deletion causing very odd corruption/skipping/repeat/pawns,"Cannot reproduce it now on betalabs.It might got fixed.So changing the status as resolved and fixed.
If you can still reproduce it, please reopen it.",task_subcomment,"Cannot reproduce it now on betalabs.It might got fixed.So changing the status as resolved and fixed.
If you can still reproduce it, please reopen it.",ACTION ON ISSUE
253425,VisualEditor: Block slug deletion causing very odd corruption/skipping/repeat/pawns,"TypeError: node.getParent(...) is null
http://bits.wikimedia.org/static-1.22wmf9/extensions/VisualEditor/modules/ve/ce/ve.ce.Surface.js
Line 1267",task_subcomment,"TypeError: node.getParent(...) is null
URL
Line 1267",BUG REPRODUCTION
53523,VisualEditor: Too many clicks needed to dismiss inlink editor,"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",task_description,"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",BUG REPRODUCTION
253365,VisualEditor: Too many clicks needed to dismiss inlink editor,This is now merged and will be deployed later.,task_subcomment,This is now merged and will be deployed later.,ACTION ON ISSUE
253362,VisualEditor: Too many clicks needed to dismiss inlink editor,"Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 merged by jenkins-bot:
Link inspector bug fixes

GERRIT_URL",ACTION ON ISSUE
253359,VisualEditor: Too many clicks needed to dismiss inlink editor,"Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

GERRIT_URL",ACTION ON ISSUE
53507,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","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",task_description,"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**:
URL
URL",SOLUTION USAGE
252473,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""",Re-closing; have made bug 56453 for the suggestion to add a new one for other keyboards.,task_subcomment,Re-closing; have made bug 56453 for the suggestion to add a new one for other keyboards.,ACTION ON ISSUE
252470,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","(In reply to comment #7)
> Except there is no \ key on keyboards like the French one, so the shortcut is
> reported as not working (also, provoking weird behaviour I'll report
> elsewhere), since they should type CTRL + Alt Gr + 8. Can we do something
> about this? Thanks.

Weird behaviour reported on https://bugzilla.wikimedia.org/show_bug.cgi?id=53682",task_subcomment,"(In reply to comment #7)
QUOTE
QUOTE
QUOTE
QUOTE

Weird behaviour reported on URL",BUG REPRODUCTION
252466,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","Except there is no \ key on keyboards like the French one, so the shortcut is reported as not working (also, provoking weird behaviour I'll report elsewhere), since they should type CTRL + Alt Gr + 8. Can we do something about this? Thanks.",task_subcomment,"Except there is no \ key on keyboards like the French one, so the shortcut is reported as not working (also, provoking weird behaviour I'll report elsewhere), since they should type CTRL + Alt Gr + 8. Can we do something about this? Thanks.",MOTIVATION
252463,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","Now merged and will go out with the next production push, probably tomorrow.",task_subcomment,"Now merged and will go out with the next production push, probably tomorrow.",SOLUTION USAGE
252458,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","Change 76666 merged by jenkins-bot:
Add keyboard shortcut for 'clear' button

https://gerrit.wikimedia.org/r/76666",task_subcomment,"Change 76666 merged by jenkins-bot:
Add keyboard shortcut for 'clear' button

GERRIT_URL",TASK PROGRESS
252452,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","Change 76666 had a related patch set uploaded by Jforrester:
Add keyboard shortcut for 'clear' button

https://gerrit.wikimedia.org/r/76666",task_subcomment,"Change 76666 had a related patch set uploaded by Jforrester:
Add keyboard shortcut for 'clear' button

GERRIT_URL",ACTION ON ISSUE
252447,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""",Ctrl + M might be a little friendlier.  I know from experience people confuse backslash and forward slash.  But I don't feel strongly about it.,task_subcomment,Ctrl + M might be a little friendlier.  I know from experience people confuse backslash and forward slash.  But I don't feel strongly about it.,SOLUTION DISCUSSION
252438,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","I can see wanting to use Ctrl + Spacebar for a general whitespace inserter menu (nbsp/tab/etc.), so how about we go with Ctrl + \?",task_subcomment,"I can see wanting to use Ctrl + Spacebar for a general whitespace inserter menu (nbsp/tab/etc.), so how about we go with Ctrl + \?",SOLUTION DISCUSSION
252433,"VisualEditor: Add a keyboard shortcut for ""Clear formatting""","Shortcuts used in other programs are:

Ctrl + Spacebar - Used by Word for ""Remove paragraph or character formatting.""/""Remove manual character formatting"" (http://support.microsoft.com/kb/290938).
Ctrl + \ - Used by Google Docs for ""Clear formatting"" (https://support.google.com/drive/answer/179738?hl=en)
Ctrl + M - Used by LibreOffice for ""Clear direct formatting"" (https://help.libreoffice.org/Common/General_Shortcut_Keys_in)",task_subcomment,"Shortcuts used in other programs are:

Ctrl + Spacebar - Used by Word for ""Remove paragraph or character formatting.""/""Remove manual character formatting"" (URL
Ctrl + \ - Used by Google Docs for ""Clear formatting"" (URL
Ctrl + M - Used by LibreOffice for ""Clear direct formatting"" (URL",SOLUTION USAGE
53502,VisualEditor: Reduce event rapid fire in CE,"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",task_description,"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",BUG REPRODUCTION
252199,VisualEditor: Reduce event rapid fire in CE,Yes.,task_subcomment,Yes.,ACTION ON ISSUE
252194,VisualEditor: Reduce event rapid fire in CE,Can we now deem this to have been done?,task_subcomment,Can we now deem this to have been done?,ACTION ON ISSUE
53477,VisualEditor: Typing in Devanagari puts vowels in unexpected places,"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",task_description,"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",BUG REPRODUCTION
250407,VisualEditor: Typing in Devanagari puts vowels in unexpected places,master looks good to me. Thanks!,task_subcomment,master looks good to me. Thanks!,SOLUTION USAGE
250400,VisualEditor: Typing in Devanagari puts vowels in unexpected places,"Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!",task_subcomment,"Given that this is now merged, I'm going to mark this as fixed. However, this is provisional - please re-open if you think that this has not worked!",ACTION ON ISSUE
250395,VisualEditor: Typing in Devanagari puts vowels in unexpected places,"Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080",task_subcomment,"Change 80080 merged by jenkins-bot:
Don't emit Surface changes back to the Surface

GERRIT_URL",ACTION ON ISSUE
250390,VisualEditor: Typing in Devanagari puts vowels in unexpected places,"Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

https://gerrit.wikimedia.org/r/80080",task_subcomment,"Change 80080 had a related patch set uploaded by Jforrester:
WIP:Don't emit Surface changes back to the Surface

GERRIT_URL",ACTION ON ISSUE
250387,VisualEditor: Typing in Devanagari puts vowels in unexpected places,"Hi, thanks for the detailed error description with the en-US key equivalents -- it really helps!

I *think* this is resolved by the following patch: https://gerrit.wikimedia.org/r/#/c/79451 . At least, the patch seems to fix the ""hindi inscript (m17n)"" ibus method on Linux.",task_subcomment,"Hi, thanks for the detailed error description with the en-US key equivalents -- it really helps!

I *think* this is resolved by the following patch: URL . At least, the patch seems to fix the ""hindi inscript (m17n)"" ibus method on Linux.",SOLUTION DISCUSSION
53472,VisualEditor: Backspace deletes combined character clusters together with diacritics,"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",task_description,"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**:
URL
URL",BUG REPRODUCTION
250125,VisualEditor: Backspace deletes combined character clusters together with diacritics,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 merged by jenkins-bot:
Revert model to use simple UTF-16 code units

GERRIT_URL",ACTION ON ISSUE
250118,VisualEditor: Backspace deletes combined character clusters together with diacritics,"Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

https://gerrit.wikimedia.org/r/80689",task_subcomment,"Change 80689 had a related patch set uploaded by Divec:
DONTMERGE:Revert model to use simple UTF-16 code units

GERRIT_URL",ACTION ON ISSUE
250110,VisualEditor: Backspace deletes combined character clusters together with diacritics,There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.,task_subcomment,There's code in progress to fix this in gerrit 80689 which is currently a work-in-progress.,SOLUTION DISCUSSION
250100,VisualEditor: Backspace deletes combined character clusters together with diacritics,"This is how we expect backspace to work with our current support of grapheme clusters. As Denis points out, being able to delete combining marks separately would have to be enabled on a per script basis, as we wouldn't want to require multiple keystrokes to remove e-acute, or a Jamo-constructed Hangul character.",task_subcomment,"This is how we expect backspace to work with our current support of grapheme clusters. As Denis points out, being able to delete combining marks separately would have to be enabled on a per script basis, as we wouldn't want to require multiple keystrokes to remove e-acute, or a Jamo-constructed Hangul character.",EXPECTED BEHAVIOR
250091,VisualEditor: Backspace deletes combined character clusters together with diacritics,"(In reply to comment #1)
> Could this be a dupe of -
> https://bugzilla.wikimedia.org/show_bug.cgi?id=49233  ?

Well, that one is marked as FIXED, and this one is definitely not fixed on master.",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE

Well, that one is marked as FIXED, and this one is definitely not fixed on master.",BUG REPRODUCTION
250081,VisualEditor: Backspace deletes combined character clusters together with diacritics,"The expected behaviour of backspace can be different with different writing systems.

In Indic scripts, as explained in the bug description, the most common behaviour is that backspace should erase one characters and delete should erase a cluster. See http://publib.boulder.ibm.com/infocenter/hodhelp/v10r0/topic/com.ibm.hod.doc/help/hindi.html#hindispecialkeys
http://www-archive.mozilla.org/projects/ctl/tests/#indiceditoper

For other scripts it might be different, particularly for Latin, Greek and Cyrillic where, because of the precomposed accented characters, it is expected that characters and character sequences (base character + combining diacritic) that represent units will behave the same way, i.e. backspace and delete erase the base and diacritic, for example the single character à and the two characters ɛ̀ should be treated the same way.

http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries talks about this.",task_subcomment,"The expected behaviour of backspace can be different with different writing systems.

In Indic scripts, as explained in the bug description, the most common behaviour is that backspace should erase one characters and delete should erase a cluster. See URL
URL

For other scripts it might be different, particularly for Latin, Greek and Cyrillic where, because of the precomposed accented characters, it is expected that characters and character sequences (base character + combining diacritic) that represent units will behave the same way, i.e. backspace and delete erase the base and diacritic, for example the single character à and the two characters ɛ̀ should be treated the same way.

URL talks about this.",INVESTIGATION AND EXPLORATION
250071,VisualEditor: Backspace deletes combined character clusters together with diacritics,"Could this be a dupe of -
https://bugzilla.wikimedia.org/show_bug.cgi?id=49233  ?",task_subcomment,"Could this be a dupe of -
URL  ?",ACTION ON ISSUE
53463,VisualEditor: Don't extend links over wordbreaks,"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",task_description,"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**:
URL",BUG REPRODUCTION
249675,VisualEditor: Don't extend links over wordbreaks,*** Bug 51531 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51531 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
249667,VisualEditor: Don't extend links over wordbreaks,Fixed and will get deployed in a few minutes.,task_subcomment,Fixed and will get deployed in a few minutes.,SOLUTION USAGE
249660,VisualEditor: Don't extend links over wordbreaks,"Change 74168 merged by jenkins-bot:
Split continued link annotations on wordbreaks

https://gerrit.wikimedia.org/r/74168",task_subcomment,"Change 74168 merged by jenkins-bot:
Split continued link annotations on wordbreaks

GERRIT_URL",ACTION ON ISSUE
249654,VisualEditor: Don't extend links over wordbreaks,"Change 74168 had a related patch set uploaded by Esanders:
[WIP] Split continued link annotations on wordbreaks

https://gerrit.wikimedia.org/r/74168",task_subcomment,"Change 74168 had a related patch set uploaded by Esanders:
[WIP] Split continued link annotations on wordbreaks

GERRIT_URL",SOLUTION USAGE
53462,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"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}",task_description,"See, for example, URL and URL - this is kinda a problem.

--------------------------
**Version**: unspecified
**Severity**: enhancement
**See Also**:
{T53509}",SOLUTION USAGE
249632,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"(In reply to comment #12)
> Reopening as this is still happening:
> first nowiki after line 133 in
> https://en.wikipedia.org/w/index.
> php?title=Pet&diff=570614739&oldid=570586939 .

That's almost certainly using a cached version of the code; I can't reproduce that on Chrome/Firefox/Safari/Opera on Mac or Linux.

(In reply to comment #13)
> I am also filing a related common problem we meet at it.wp.
> If this is not the right place, just tell me and I'll copy/paste my report
> elsewhere.

Yeah, if you could file this as a new bug please - this is not related to removing whitespace from the start of paragraphs.",task_subcomment,"(In reply to comment #12)
QUOTE
QUOTE
QUOTE
QUOTE

That's almost certainly using a cached version of the code; I can't reproduce that on Chrome/Firefox/Safari/Opera on Mac or Linux.

(In reply to comment #13)
QUOTE
QUOTE
QUOTE

Yeah, if you could file this as a new bug please - this is not related to removing whitespace from the start of paragraphs.",ACTION ON ISSUE
249627,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"I am also filing a related common problem we meet at it.wp.
If this is not the right place, just tell me and I'll copy/paste my report elsewhere.

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.",task_subcomment,"I am also filing a related common problem we meet at it.wp.
If this is not the right place, just tell me and I'll copy/paste my report elsewhere.

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 URL .

We actually found a workaround for this: URL 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 URL .

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 URL 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.",SOLUTION DISCUSSION
249623,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"Reopening as this is still happening:
first nowiki after line 133 in https://en.wikipedia.org/w/index.php?title=Pet&diff=570614739&oldid=570586939 .",task_subcomment,"Reopening as this is still happening:
first nowiki after line 133 in URL .",BUG REPRODUCTION
249618,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(",task_subcomment,"Now fixed in the code; next scheduled deployment is not until 15 August,
however. :-(",ACTION ON ISSUE
249615,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"Change 77287 merged by jenkins-bot:
Remove inserted leading whitespace

https://gerrit.wikimedia.org/r/77287",task_subcomment,"Change 77287 merged by jenkins-bot:
Remove inserted leading whitespace

GERRIT_URL",ACTION ON ISSUE
249613,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"So I just implemented a fix for this, but it broke a test that asserts that whitespace inside a pre is untouched. I'll put it a check for 
     elements but we should be aware that this is broken, because any element can have white-space:pre attached to it, e.g.

    Foo

Will now normalise to

Foo

Long term we should look into just warning the user.",task_subcomment,"So I just implemented a fix for this, but it broke a test that asserts that whitespace inside a pre is untouched. I'll put it a check for 
     elements but we should be aware that this is broken, because any element can have white-space:pre attached to it, e.g.

    Foo

Will now normalise to

Foo

Long term we should look into just warning the user.",SOLUTION DISCUSSION
249611,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"Change 77287 had a related patch set uploaded by Esanders:
[WIP] Remove inserted leading whitepsace

https://gerrit.wikimedia.org/r/77287",task_subcomment,"Change 77287 had a related patch set uploaded by Esanders:
[WIP] Remove inserted leading whitepsace

GERRIT_URL",TASK PROGRESS
249608,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"(In reply to comment #5)
> With bug 50841 we now convert 
> 
> [space]Foo
> 
> to
> 
>  Foo
> 
> (previously  Foo)
> 
> This is the correct behaviour.

Also, with gerrit 76223 VisualEditor users can now edit through s transparently.

> Perhaps this, and other whitespace issues (e.g. double
> spaces), should be flagged up to the user (with a wiggle underline?)

That would be one solution that is quite generalisable, but could be a great deal more work.",task_subcomment,"(In reply to comment #5)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

Also, with gerrit 76223 VisualEditor users can now edit through s transparently.

QUOTE
QUOTE

That would be one solution that is quite generalisable, but could be a great deal more work.",SOLUTION DISCUSSION
249605,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,*** Bug 52252 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52252 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
249601,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"With bug 50841 we now convert 

[space]Foo

to

 Foo

(previously  Foo)

This is the correct behaviour.

We should be careful going do the road of automatically correcting what we believe to be typos. Perhaps this, and other whitespace issues (e.g. double spaces), should be flagged up to the user (with a wiggle underline?)",task_subcomment,"With bug 50841 we now convert 

[space]Foo

to

 Foo

(previously  Foo)

This is the correct behaviour.

We should be careful going do the road of automatically correcting what we believe to be typos. Perhaps this, and other whitespace issues (e.g. double spaces), should be flagged up to the user (with a wiggle underline?)",SOLUTION DISCUSSION
249598,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,*** Bug 51509 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51509 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
249594,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"Without whitespace stripping (either in VE or Parsoid) and no nowiki, that text will become 
    -formatted.

Quickly discussed with Gabriel on IRC. It is probably better fixed in VE since Parsoid doesn't have contextual information about where the space is meaningful or not.

If leading whitespace at start of line is desired by the editor, then VE should convert them to   or if nowikis are acceptable, the spaces can be left alone.  In either case, this kind of edits should hopefully be rare.",task_subcomment,"Without whitespace stripping (either in VE or Parsoid) and no nowiki, that text will become 
    -formatted.

Quickly discussed with Gabriel on IRC. It is probably better fixed in VE since Parsoid doesn't have contextual information about where the space is meaningful or not.

If leading whitespace at start of line is desired by the editor, then VE should convert them to   or if nowikis are acceptable, the spaces can be left alone.  In either case, this kind of edits should hopefully be rare.",SOLUTION DISCUSSION
249587,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,"If VE can strip leading whitespace in paragraphs, that will eliminate these errors.  Alternatively, Parsoid can do that normalization. Unclear where this should be done.  Will discuss on IRC.",task_subcomment,"If VE can strip leading whitespace in paragraphs, that will eliminate these errors.  Alternatively, Parsoid can do that normalization. Unclear where this should be done.  Will discuss on IRC.",SOLUTION DISCUSSION
249579,VisualEditor: Strip whitespace from the start of paragraphs before sending to Parsoid,and https://en.wikipedia.org/w/index.php?title=John_Altoon&diff=prev&oldid=564536250,task_subcomment,and URL,ACTION ON ISSUE
53459,VisualEditor: Show the  message when creating a new article,"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",task_description,"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: URL

VE: URL

--------------------------
**Version**: unspecified
**Severity**: trivial",BUG REPRODUCTION
249429,VisualEditor: Show the  message when creating a new article,Fixed and will get deployed in a few minutes.,task_subcomment,Fixed and will get deployed in a few minutes.,SOLUTION USAGE
249420,VisualEditor: Show the  message when creating a new article,"Change 75563 merged by jenkins-bot:
Show newarticletext(anon) when creating a new page

https://gerrit.wikimedia.org/r/75563",task_subcomment,"Change 75563 merged by jenkins-bot:
Show newarticletext(anon) when creating a new page

GERRIT_URL",ACTION ON ISSUE
249414,VisualEditor: Show the  message when creating a new article,"Change 75563 had a related patch set uploaded by Esanders:
Show newarticletext(anon) when creating a new page

https://gerrit.wikimedia.org/r/75563",task_subcomment,"Change 75563 had a related patch set uploaded by Esanders:
Show newarticletext(anon) when creating a new page

GERRIT_URL",TASK PROGRESS
249409,VisualEditor: Show the  message when creating a new article,"The resolution of Bug 51160 gives me hope. French Wikipedia transcludes Talk:.../Suppression subpages for some deleted articles.
 
https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial%3ARecherche&profile=advanced&search=Suppression&fulltext=Search&ns1=1&redirs=1&profile=advanced",task_subcomment,"The resolution of Bug 51160 gives me hope. French Wikipedia transcludes Talk:.../Suppression subpages for some deleted articles.
 
URL",SOLUTION USAGE
249406,VisualEditor: Show the  message when creating a new article,"@James, before marking this trivial, I hope you did an impact assessment on
1. https://de.wikipedia.org/wiki/MediaWiki:Newarticletext-0
2. https://es.wikipedia.org/wiki/MediaWiki:Newarticletext
3. https://fr.wikipedia.org/wiki/MediaWiki:Newarticletext
4. https://he.wikipedia.org/wiki/MediaWiki:Newarticletext
5. https://it.wikipedia.org/wiki/MediaWiki:Newarticletext
6. https://nl.wikipedia.org/wiki/MediaWiki:Newarticletext
7. https://pl.wikipedia.org/wiki/MediaWiki:Newarticletext
8. https://ru.wikipedia.org/wiki/MediaWiki:Newarticletext
9. https://sv.wikipedia.org/wiki/MediaWiki:Newarticletext

I know you didn't, because on at least one of those projects there is critical functionality in this message.  Since you and O Keyes (on a different bug about missing interface messages) are being so rude, I'll let you find out the hard way.",task_subcomment,"SCREEN_NAME, before marking this trivial, I hope you did an impact assessment on
1. URL
2. URL
3. URL
4. URL
5. URL
6. URL
7. URL
8. URL
9. URL

I know you didn't, because on at least one of those projects there is critical functionality in this message.  Since you and O Keyes (on a different bug about missing interface messages) are being so rude, I'll let you find out the hard way.",ACTION ON ISSUE
249404,VisualEditor: Show the  message when creating a new article,"(In reply to comment #1)
> This is something that obviously must be fixed before VE is enabled by
> default, which is planned for Real Soon Now(tm).

By default for whom on which wiki? It's been enabled by default on enwiki since 1 July for logged-in users and since 15 July for anonymous users too.",task_subcomment,"(In reply to comment #1)
QUOTE
QUOTE

By default for whom on which wiki? It's been enabled by default on enwiki since 1 July for logged-in users and since 15 July for anonymous users too.",SOLUTION DISCUSSION
249401,VisualEditor: Show the  message when creating a new article,"This is something that obviously must be fixed before VE is enabled by default, which is planned for Real Soon Now(tm).",task_subcomment,"This is something that obviously must be fixed before VE is enabled by default, which is planned for Real Soon Now(tm).",SOLUTION DISCUSSION
53439,VisualEditor: Inspectors and context menu should close when blurring the document and/or when opening the save dialog,"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",task_description,"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",BUG REPRODUCTION
248279,VisualEditor: Inspectors and context menu should close when blurring the document and/or when opening the save dialog,"Confirmed, the link and language inspectors close on triggering the save dialog.",task_subcomment,"Confirmed, the link and language inspectors close on triggering the save dialog.",BUG REPRODUCTION
248274,VisualEditor: Inspectors and context menu should close when blurring the document and/or when opening the save dialog,"Is this fixed now? I can't reproduce this any more. Clicking Save page closes the link inspector for me, and it seems to save the changes correctly too.",task_subcomment,"Is this fixed now? I can't reproduce this any more. Clicking Save page closes the link inspector for me, and it seems to save the changes correctly too.",BUG REPRODUCTION
248268,VisualEditor: Inspectors and context menu should close when blurring the document and/or when opening the save dialog,*** Bug 63050 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 63050 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
248263,VisualEditor: Inspectors and context menu should close when blurring the document and/or when opening the save dialog,"Same for context menu (e.g. focus a link, but don't open the inspector yet)",task_subcomment,"Same for context menu (e.g. focus a link, but don't open the inspector yet)",SOLUTION DISCUSSION
53415,"VisualEditor: Link inspector ignores typed text if user presses [enter] too quickly, explodes with new links","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",task_description,"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",BUG REPRODUCTION
246849,"VisualEditor: Link inspector ignores typed text if user presses [enter] too quickly, explodes with new links",This is now merged and will be deployed later.,task_subcomment,This is now merged and will be deployed later.,ACTION ON ISSUE
246845,"VisualEditor: Link inspector ignores typed text if user presses [enter] too quickly, explodes with new links","Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 merged by jenkins-bot:
Link inspector bug fixes

GERRIT_URL",ACTION ON ISSUE
246840,"VisualEditor: Link inspector ignores typed text if user presses [enter] too quickly, explodes with new links",*** Bug 52344 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 52344 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
246834,"VisualEditor: Link inspector ignores typed text if user presses [enter] too quickly, explodes with new links","Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

GERRIT_URL",ACTION ON ISSUE
53406,VisualEditor: Transclusion dialog should prevent adding identically-named parameters (and aliases),"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",task_description,"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",SOLUTION DISCUSSION
246302,VisualEditor: Transclusion dialog should prevent adding identically-named parameters (and aliases),"I'm going to assume ""yes"" given testing.",task_subcomment,"I'm going to assume ""yes"" given testing.",SOLUTION DISCUSSION
246297,VisualEditor: Transclusion dialog should prevent adding identically-named parameters (and aliases),Works for me... Has this been fixed since it was reported?,task_subcomment,Works for me... Has this been fixed since it was reported?,TASK PROGRESS
53404,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"* 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",task_description,"* 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",BUG REPRODUCTION
246201,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,*** Bug 51984 has been marked as a duplicate of this bug. ***,task_subcomment,*** Bug 51984 has been marked as a duplicate of this bug. ***,BUG REPRODUCTION
246197,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,This is now merged and will be deployed later.,task_subcomment,This is now merged and will be deployed later.,ACTION ON ISSUE
246192,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"Change 76839 merged by jenkins-bot:
Link inspector bug fixes

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 merged by jenkins-bot:
Link inspector bug fixes

GERRIT_URL",ACTION ON ISSUE
246187,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

https://gerrit.wikimedia.org/r/76839",task_subcomment,"Change 76839 had a related patch set uploaded by Trevor Parscal:
The greatest commit in the history of the world*

GERRIT_URL",ACTION ON ISSUE
246178,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"I can reproduce this by putting the cursor on a blank line (such as an empty page), clicking link inspector icon, then pressing key 'Esc'.",task_subcomment,"I can reproduce this by putting the cursor on a blank line (such as an empty page), clicking link inspector icon, then pressing key 'Esc'.",BUG REPRODUCTION
246171,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"Bug 51415 is reporting the same JS error in the same component, with different steps to reproduce.",task_subcomment,"Bug 51415 is reporting the same JS error in the same component, with different steps to reproduce.",BUG REPRODUCTION
246165,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,I've just tested this and can reproduce it except for comment 3 - in my test I was able to do everything except link and the save worked as expected.,task_subcomment,I've just tested this and can reproduce it except for comment 3 - in my test I was able to do everything except link and the save worked as expected.,BUG REPRODUCTION
246159,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"It could be just be, but I run into this quite often. Every time it happens the interface crashes unrecoverably and all work is lost.",task_subcomment,"It could be just be, but I run into this quite often. Every time it happens the interface crashes unrecoverably and all work is lost.",BUG REPRODUCTION
246153,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"Created attachment 12854
Screenshot of problem

**Attached**: {F11587}",task_subcomment,"Created attachment 12854
Screenshot of problem

**Attached**: {F11587}",BUG REPRODUCTION
246147,VisualEditor: Link inspector crashes when inserting link on non-linkable or empty selection,"Note, this doesn't seem a race condition or anything. I'm giving it at least half a second to a second of time between each distinct action.",task_subcomment,"Note, this doesn't seem a race condition or anything. I'm giving it at least half a second to a second of time between each distinct action.",BUG REPRODUCTION
53403,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","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}",task_description,"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] URL

--------------------------
**Version**: unspecified
**Severity**: normal

**Attached**: {F11585}",SOLUTION DISCUSSION
246097,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property",We will deploy this fix today.,task_subcomment,We will deploy this fix today.,ACTION ON ISSUE
246089,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","Change 73895 merged by jenkins-bot:
Really parse the API warning in the APIEditBeforeSave hook

https://gerrit.wikimedia.org/r/73895",task_subcomment,"Change 73895 merged by jenkins-bot:
Really parse the API warning in the APIEditBeforeSave hook

GERRIT_URL",ACTION ON ISSUE
246082,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","(Sorry, if my last comment was unlcear:) Showing the full warning message, I mean.",task_subcomment,"(Sorry, if my last comment was unlcear:) Showing the full warning message, I mean.",SOLUTION DISCUSSION
246074,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","(In reply to comment #2)
> I don't think this is really what people want to be doing (regardless of
> whether HTML is being presented by this call or not). Take a look at filter
> 554
> on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554).
> Note how it triggers a message of abusefilter-top100. That causes the
> standard
> wikitext editor to display
> http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which
> explains what's wrong with the edit. That's what you need to display, not the
> short description (in this case ""top100 blog charts"", which doesn't mean
> squat
> to a new editor).

That's exactly what we're trying to do.",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

That's exactly what we're trying to do.",SOLUTION DISCUSSION
246065,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","Change 73895 had a related patch set uploaded by Hoo man:
Really parse the API warning in the APIEditBeforeSave hook

https://gerrit.wikimedia.org/r/73895",task_subcomment,"Change 73895 had a related patch set uploaded by Hoo man:
Really parse the API warning in the APIEditBeforeSave hook

GERRIT_URL",ACTION ON ISSUE
246055,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property","**kwwilliams** wrote:

I don't think this is really what people want to be doing (regardless of whether HTML is being presented by this call or not). Take a look at filter 554 on English Wikipedia (http://en.wikipedia.org/wiki/Special:AbuseFilter/554). Note how it triggers a message of abusefilter-top100. That causes the standard wikitext editor to display http://en.wikipedia.org/w/index.php?title=MediaWiki:abusefilter-top100 which explains what's wrong with the edit. That's what you need to display, not the short description (in this case ""top100 blog charts"", which doesn't mean squat to a new editor).",task_subcomment,"**kwwilliams** wrote:

I don't think this is really what people want to be doing (regardless of whether HTML is being presented by this call or not). Take a look at filter 554 on English Wikipedia (URL Note how it triggers a message of abusefilter-top100. That causes the standard wikitext editor to display URL which explains what's wrong with the edit. That's what you need to display, not the short description (in this case ""top100 blog charts"", which doesn't mean squat to a new editor).",SOLUTION DISCUSSION
246047,"AbuseFilter: API is responding with wikitext instead of HTML in the ""warning"" property",That's because Status::getHTML isn't actually doing real parsing... going to look at this tomorrow,task_subcomment,That's because Status::getHTML isn't actually doing real parsing... going to look at this tomorrow,SOLUTION DISCUSSION
53375,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

whatever VE decides to do with ""illegal"" values is an interesting question, but TD itself should allow distinction between ""suggested values"" and ""legal values"", because the template syntax itself makes this distinction.  VE can ignore this distinction or not, but TD should provide this information.

suggestedvalues serves templates that use {{#switch, and there are several different behaviors when param value is not present as one of the options: 
  - the switch may have #default, which does something useful - IOW, an ""unsuggested"" value is still legal
  - it can have no #default, practically ignoring the value
  - the #default can trigger an error.

TD syntax should allow better description of the behavior, so, e.g., ""template linting"" tools can detect and flag pages where a template with ""suggested values"" is used with ""unsuggested"" value: it can be an error worth flagging (2nd and 3rd cases above, where suggested values really means legal values), and not flag it for parameters whose behavior match the 1st case. 

this is not a theoretical/hypothetical issue - such tools exist, and are used on several projects (see, e.g., Module:ParamValidator on hewiki and yiwiki).

peace.",task_subcomment,"we should distinguish between visualeditor and templatedata.
templatedata provides a syntax to describe the template behavior, and is used not just by visualeditor, but other tools too.

whatever VE decides to do with ""illegal"" values is an interesting question, but TD itself should allow distinction between ""suggested values"" and ""legal values"", because the template syntax itself makes this distinction.  VE can ignore this distinction or not, but TD should provide this information.

suggestedvalues serves templates that use {{#switch, and there are several different behaviors when param value is not present as one of the options: 
  - the switch may have #default, which does something useful - IOW, an ""unsuggested"" value is still legal
  - it can have no #default, practically ignoring the value
  - the #default can trigger an error.

TD syntax should allow better description of the behavior, so, e.g., ""template linting"" tools can detect and flag pages where a template with ""suggested values"" is used with ""unsuggested"" value: it can be an error worth flagging (2nd and 3rd cases above, where suggested values really means legal values), and not flag it for parameters whose behavior match the 1st case. 

this is not a theoretical/hypothetical issue - such tools exist, and are used on several projects (see, e.g., Module:ParamValidator on hewiki and yiwiki).

peace.",SOLUTION DISCUSSION
1684699,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","This can most certainly be closed via {T271825}. While it's not 100% the same, it should be sufficient to resolve the relevant use case.",task_subcomment,"This can most certainly be closed via {T271825}. While it's not 100% the same, it should be sufficient to resolve the relevant use case.",SOLUTION USAGE
1448999,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","A suggestion from https://www.mediawiki.org/wiki/Topic:Ve06hyihctm4p86n is to allow labels different from the actual value. It can be stored for example with:
```lang=json
""params"": {
	""key"": {
		""type"": ...,
		""values"": [
			{""label"": ..., ""value"": ...},
			...
		]
	}
}
```
Maybe plain strings should also be allowed for convenience, which could be transformed by the extension to
```lang=json
{""label"": null, ""value"": ...}
```
form. (I’d also suggest to always display the actual value in addition to the label, but that’s up to the consumers, of course.)",task_subcomment,"A suggestion from URL is to allow labels different from the actual value. It can be stored for example with:
``CODE`CODE`CODE``
form. (I’d also suggest to always display the actual value in addition to the label, but that’s up to the consumers, of course.)",SOLUTION DISCUSSION
1112189,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params",task_subcomment,"Is this still on the docket? It's vital. Is there some other way of specifying valid string values in TemplateData (TD)? If not, that would appear to be a large oversight if TD is supposed to help users easily interact with template params",SOLUTION DISCUSSION
957154,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","That's something which would be extremely useful.

I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…). ",task_subcomment,"That's something which would be extremely useful.

I'm currently working on a proposal for ease Wikitionary contribution through templatedata. Such a feature would for example allow to select word category (verb, adjective…). ",SOLUTION DISCUSSION
787891,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","Change 263655 had a related patch set uploaded (by Alex Monk):
[WIP] Add a parameter key to limit possible valid values to a given set

[[https://gerrit.wikimedia.org/r/263655]]
",task_subcomment,"Change 263655 had a related patch set uploaded (by Alex Monk):
[WIP] Add a parameter key to limit possible valid values to a given set

[[GERRIT_URL]]
",ACTION ON ISSUE
444533,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

```
 params: {
  ""key"": {
    ""type"": ...
    ""values"": [ .. ]
```

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

```
 params: {
  ""key"": {
    ""type"": ""options""
    ""values"": [ .. ]
```

And would treat them as type: 'string' with no further type association.

It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",task_subcomment,"Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

``CODE`CODE`CODE``

And would treat them as type: 'string' with no further type association.

It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",SOLUTION DISCUSSION
434600,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

params: {
  ""key"": {
    ""type"": ...
    ""values"": [ .. ]

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

params: {
  ""key"": {
    ""type"": ""options""
    ""values"": [ .. ]

And would treat them as type: 'string' with no further type association.

It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",task_subcomment,"Yeah, we should add this. Though it doesn't have to be as a parameter type. I imagine we could also do it more generically.

params: {
  ""key"": {
    ""type"": ...
    ""values"": [ .. ]

The upside is that this is easier to specify and validate.

An nice bonus is that it would allow one to preserve types regardless of whether the possible values are finite or not (e.g. freeform strings, numbers, dates, page names).

Down side is that it's tricky for consumers like VisualEditor to have a dropdown menu for values that aren't simple strings.

But I think that's fine. Those consumers can choose to support it however they like. E.g. they could support ""values"" only for string values.

As a nice bonus this would allow VisualEditor to make dedicated select interfaces much better. E.g. a colour picker with limited values could be a row with squares and you visually pick one of those colours (like radio buttons). And a parameter that takes file names (e.g. for icons), could have live previews for the 10 different icons it supports.

The type-restricted implementation would look something like this:

params: {
  ""key"": {
    ""type"": ""options""
    ""values"": [ .. ]

And would treat them as type: 'string' with no further type association.

It also has the downside of having a ""param"" property (values) that only makes sense in combination with another. Making it slightly less intuitive.",SOLUTION DISCUSSION
244441,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","(In reply to comment #2)
> Ping @TrevorParscal.
> 
> Since wikitext template editing will always be possible, we can't (yet?)
> enforce values in VisualEditor. We can only suggest.
> 
> E.g. if a template parameter ""foo"" is specified as values: ['a', 'b']. and
> wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while
> still
> being able to set it to a or b.

The ""normal"" way is a drop-down with the target of the drop-down being a free-entry text field that suggests entries (but does not block other entries).",task_subcomment,"(In reply to comment #2)
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE
QUOTE

The ""normal"" way is a drop-down with the target of the drop-down being a free-entry text field that suggests entries (but does not block other entries).",SOLUTION USAGE
244428,"TemplateData: Add parameter type for selecting one of predefined values (like """" or ENUM)","Ping @TrevorParscal.

Since wikitext template editing will always be possible, we can't (yet?) enforce values in VisualEditor. We can only suggest.

E.g. if a template parameter ""foo"" is specified as values: ['a', 'b']. and wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while still being able to set it to a or b.",task_subcomment,"PingSCREEN_NAME.

Since wikitext template editing will always be possible, we can't (yet?) enforce values in VisualEditor. We can only suggest.

E.g. if a template parameter ""foo"" is specified as values: ['a', 'b']. and wikitext has {{echo|foo=x}}, we need to provide a way to edit that, while still being able to set it to a or b.",MOTIVATION
244412,"TemplateData: Add parameter type for selecting one of predefined values (like ""